One of the most significant risks to the project is the complexity of integrating multiple software components together with the hardware layer. Because the system depends on several stages working seamlessly, any mismatch in interfaces or unexpected behavior during integration could delay progress. To manage this risk, we are intentionally designing the system to be highly modular, with clearly defined boundaries and data formats between components. Each module will be developed and validated independently through thorough test cases before being connected to the rest of the system. This approach allows us to verify correctness at the component level first, making integration more predictable and easier to debug.
Specifically a major risk for the project is the reliable nature of interpreting the sheet music under real-world conditions, in which given the factors of scan quality, lighting, and perspectives of the sheet music can affect accuracy of extracting necessary information and unfortunately if there are errors at this stage it would affect the final result of the LED. To manage this risk, the team will plan to design a software pipeline that will provide preprocessing, validation, and modular testing at each stage allowing inaccuracies to be noticeable and isolated before putting together other components.
An additional risk involves the responsiveness requirements that we set for the full system starting from the user input to LED output. The latency that will come from software processing, verification logic, and the software-hardware communication is something that is necessary to mitigate. To avoid these risks, we will measure the end-to-end latency across components, optimize paths, and avoid blocking operations between subsystems. If accuracy or latency measures are not met within the timeline, some backup plans include supporting alternative digital input formats or simplifying processing to maintain a functional user experience.
There is also a risk of hardware-related issues, such as FSR strip malfunctions or defects in the LED components, which are distinct from software bugs. To mitigate these risks, we plan to keep spare parts on hand and maintain fallback options. If FSR strips prove unreliable, we will explore alternative input methods such as IMU-based detection or MIDI input.
A minor change was made to the hardware sensing design during this stage of development. The original design assumed force-sensitive resistors (FSRs) would be used as the primary method for detecting key presses. After initial testing and evaluation, we decided to keep alternative sensing methods, such as IMU-based detection or MIDI input, as fallback options in case FSR reliability, durability, or sensitivity becomes a limitation in real use. This change was necessary to reduce technical risk early in development and ensure that the system can still meet functional requirements if the primary sensing method proves unreliable. The main costs associated with this change include purchasing additional components for testing and prototyping, as well as the extra time required to evaluate multiple sensing approaches. These costs will be mitigated by performing early validation to determine the most reliable sensing method and standardizing on a single solution once testing is complete.