Robot Rock

Risk Analysis

Summary

The (Incomplete)three major concerns from our requirements document (performance, music quality, and usability) are still present as risks in our design spec. Much of the design has been oriented around preventing and mitigating these risks, such as the development of the Score as a large data structure that will contain all the music that has been written by the musicians, and which will be parsed by the parser and passed onto the audio synthesizer. Two new risks that have emerged during the design phase are Synchronization and Packaging. Synchronization deals with making sure that the musicians and parser behave appropriately in relation to each other, and both keep up with each and the beat of the song. Packaging is a risk primarily because none of the members of our group has experience packaging and releasing applications or installers for applications, so it is important that the team begins thinking about packaging early and is not surprised by any complications at the deadline.

Risk: Performance/Responsiveness

• Chance of occurringoccurring: (High, Med, Low)Medium
• Impact if it occurs (H,M,L)Medium
• Steps taking to increase chance it won't occur: The setup of the musician and score design should enable users to make changes that affect the music in real time. The score will be set up such that a measure can be overwritten before it gets passed off to the parser if some instrument settings are changed.
• Mitigation plan should it occuroccur: The ideal scenario is that the musicians and parser will be separated by a very small number of beats. This number of beats that separates the two can always be modified, and if there is some delay between the user changing an option and that being reflected in the audio output, it should not be a show stopper.

Risk: Music Quality

• Chance of occurringoccurring: (High, Med, Low)Medium
• Impact if it occurs (H,M,L)occurs: High
• Steps taking to increase chance it won't occur: Created a Score that all musicians will be able to refer to what other musicians played previously, and what is currently being played for the musicians that decided before it. This design should allow musicians to easily gather data about what others are playing to assist its own decisions. This should allow us to maintain the slight delay between musicians and parser and still give real time feedback.
• Mitigation plan should it occur: The most probable cause of risk here is that the musicians computations are unable to keep up with the speed of the song, and the musicians will be most susceptible to this in high tempo, high energy situations where the computations will be complex and have a short period of time to run. If this does not occur frequently, a musician can just be passed (play nothing) if it does not meet the time requirement and the song will go on, but if the problem is consistent, then the maximum tempo may need to be reduced, and more resources dedicated to the efficiency of AI algorithms.

Risk: Synchronization

• Chance of occurringoccurring: (High, Med, Low)Low
• Impact if it occursoccurs: (H,M,L):High
• Steps taking to increase chance it won't occur: Creating a Metronome class that will control the timing of both the ensemble (Conductor class) and Audio Synthesis (Parser class). The ensemble will always be a fixed number of ticks ahead of the parser.
• Mitigation plan should it occur: If the either section is falling behind,a few options exist. If they only fall behind on rare occasions, the delay between the two can be increased to allow for those extreme cases to be handled. If it is a consistent problem (particularly at high tempos), the maximum tempo may need to be limited because that is when the largest strain will be placed on the musician and audio synthesis system.

Risk: Usability

• Chance of occurringoccurring: (High, Med, Low)Medium
• Impact if it occursoccurs: (H,M,L)High
• Steps taking to increase chance it won't occuroccur: User tests are great here. Whenever a new UI feature is developed, the developers will take a couple minutes to check it out. Asking others in the work area to sit down with it for a couple minutes will also ensure that development resources are not wasted implementing features that people do not want or understand. A tutorial will also be developed to teach new users the basics of how to get started.
• Mitigation plan should it occuroccur: Should the test users have significant difficulty understanding, dedicate more development resources to modifying the tutorial in order to be clearer and more concise. If features need to be removed/hidden to reduce complexity, focus on removing buttons/features that are causing confusion, and that few users use.

Risk: Packaging

• Chance of occurringoccurring: (High, Med, Low)Low
• Impact if it occursoccurs: (H,M,L)Low
• Steps taking to increase chance it won't occur: Assigned a team member (Travis) to be responsible for considering installation early and often. This should prevent the packaging process form becoming a major headache down the road. Our goal is to be able to provide a Windows installer, as well as the required Linux installer.installer, because we would like the application to be usable by the large majority of users.
• Mitigation plan should it occur: We may have to put off the Windows installer in the event that it is much more complicated than we anticipate.anticipate, at least until after the project due date.