Your team will hold a gate review with your guide at the end of each semester. This page should document any information needed for the review, as well as outcomes.
MSD I: Reflection and Readiness for MSD II Work
- Use this space to organize information for your review. Key elements are listed here
- Your team should complete a self-critique and report the results here.
- Note: lack of readiness means your team will have a critical design review at the end of the first phase of MSD II. This is typically a result of significant unanswered feasibility questions with no clear path to solution.
Self-Critique: MSD I Self-critique.xlsx
Expectations
- All team members present and prepared to report on team and individual status.
- All team MSD deliverables are complete and uploaded, and ready to be graded.
- Guide is present and prepared to evaluate all items included in the review.
- Review should take about an hour.
Status Review
Current state of the project
- Summarize expected performance vs. requirements (include snapshot of current requirements document here, along with a link to the live document.)
COVID and the sudden remote working requirement disrupted our plans for testing and prototyping during the end of MSD I, but we were able to perform limited testing and focus our efforts on research and preparation for MSD II. We believe we fulfilled our objectives for MSD I, and have addressed or are adequately prepared to address all design requirements in MSD II to deliver a functional prototype.
- Address any issues raised during your Detailed Design Review. These will generally fall into one of three categories
- Issues that have been addressed and the team is closing them out. (GREEN, team is ready to proceed to build and test)
- Issues that have not been addressed yet, but the team has a clear path to a solution. (YELLOW, team expects to be ready for build and test, and a Critical Design Review may be held in MSD II Week 2)
- Issues where the team has not been able to identify a solution or a clear path to a solution. (RED, team is not ready for build and test, and a Critical Design Review will be held in MSD II Week 2)
No major issues raised in Detailed Design review.
Misc Updates:
- Risk Management Document reorganized to sort by importancefrom highest to lowest.
- Documentation and links up to date on main pages of wiki (Project Overview)
- Compare your current project plan/schedule to your original plan/schedule.
- Has the scope of your project changed?
- How and why did your schedule change?
- What have you learned from these changes?
The project is mostly on schedule, though some of the prototyping we hoped to do was disrupted by the move to remote work. This was out of our control, but we adapted and did some limited prototyping at home while focusing on the larger design aspect to be ready for MSD II and eventual prototyping. Still, we believe we have a solid design foundation to begin MSD II with the prototyping and testing we missed, which will help us finalize other aspects of the design and move on to building and large-scale testing.
- Review individual team member status.
- Did you deliver on your personal responsibilities?
- Did you use your MSD I plan effectively? Was it realistic? If not already addressed above, what did you learn from this and how have you applied this toward a meaningful and realistic MSD II plan?
- Compare your current risk assessment to your original.
- Have you closed out your most important risks?
- Do you have remediation plans for remaining risks?
- Have any of these risks manifested themselves as problems?
- How did your risk assessment change? What can you learn from this?
Our risks were mostly long-term, with many tied to being able to test and prototype, and that didn't fully happen during MSD I. So, we can't exactly say that we closed out many risks, but the likelihood on several was decreased throughout the semester as we did research, understood how components would interact, and performed limited testing. More than half of the risks are at the lowest likelihood rating.
Remediation of the remaining risks will be done through the prototyping and testing in the first couple weeks of MSD II. Some risks, such as the long-lead time risk due to COVID-19, can be mitigated by ramping up purchasing during the summer.
We haven't encountered problems due to these risks yet, as we have taken them into consideration during design. Prototyping and testing will be needed to show if other risks and problems emerge as we continue the project.
Biggest risk change was the introduction of COVID-19 risks. We couldn't necessarily prepare for this sort of thing, but it shows that some risks need to be more creative and far reaching, even if unlikely.
Review your team's MSD II schedule (if not done during DDR)
- Your schedule demonstrates that you can deliver a functional prototype to your customer by your final phase demo.
- Your schedule incorporates lessons learned from your MSD I reflection.
- Spring-finish teams should include a vision for their Imagine RIT exhibit.
Heavily dependent on online/in-person class situation in the fall - schedule will be clearer mid-summer. Current plan is to spend the first two weeks performing tests and prototyping to address high-risk items and current risks, making up for lost opportunity in MSD I. Ideally, long-lead time items and any items needed for quick prototyping will be purchased at the end of summer, so they arrive in the first couple weeks.
Notable tests and steps:
- Stress and speed test the actuators
- Interface microcontroller with motors (test motor driver) - demonstrate tempo and beat control with software tests
- Prototype drum stick - motor mount
- Prepare software early so components can be tested with the microcontroller as they become available
Following the early prototyping phase, we will have enough information to finalize some design aspects and move on to large-scale prototyping and building. We plan to follow the MSD II schedule outline, with a heavy focus on building and delivering a functional prototype.
Deliverables Checklist and Website Status
- All documents must be uploaded to your website in advance of the Gate Review.
- The team should not use gate review time to conduct a detailed examination of specific deliverables unless related to discussion items in the status review.
MSD II: Project close-out
- Use this space to organize information for your review. Key elements are listed here
Expectations
- All team members present and prepared to report on team and individual status.
- All team MSD deliverables are complete and uploaded, and ready to be graded.
- Guide is present and prepared to evaluate all items included in the review.
- Review should take about an hour.
Status Review
Current state of the project
- Summarize actual performance vs. requirements (include snapshot of current requirements document here, along with a link to the live document.).
- Which requirements were unmet, and why?
- How robust is your final design?
- Did you meet your project budget?
- What was your customer's assessment of the work you delivered to them? Were they satisfied?
Design vs Requirements Live Document
Unmet requirements are those requiring longer-term tracking and analysis, such as long-term durability. There is also the weight aspect of the portability requirement, which wasn't as closely followed in favor of other portability measures. Weight is also a difficult measure due to the three different instruments and arrangement strategies, as the snare mount can work without the stand.
The final design is fairly robust, with the snare and bass mounts using components made for their respective drums (percussion claw and bass pedal). The hi-hat mount is custom but very sturdy. The electronics are expected to last through normal use of the device with the current-limiting resistors protecting the motors.
The project was completed within the original $1000 budget, including prototyping equipment and unused items from designs that were changed. The majority of purchased components were able to be included in the final prototype sent with the customer, indicating efficient use of supplies.
Customer and end-users appear to be very satisfied. The handoff meeting went well, and we've received video of the device being used in the classroom.
- Compare your current project plan/schedule to your original plan/schedule.
- Did the scope of your project change during MSD II?
- How and why did your schedule change during MSD II?
- What have you learned from these changes that you can apply to future projects?
Project scope didn't change too much, most notable design update was the beat programming board, which was just altering the interface for the same functionality.
Scheduling changes came about due to the progress of testing and building various components. Many tests weren't doable until the h bridge circuits were finalized and the striking mechanisms built, so adjustments in schedule largely followed the status of tests throughout the build. As subsystems were delayed due to redesigns or waiting for material delivery, tasks that depend on that subsystem would get shifted as well.
The most important lesson is working on finishing designing and moving into testing as early as possible so alterations and new parts can be figured out very early. There's also the need for supporting additional testing methods, such as simulations and going through the ordering phase for bigger purchases early (before design is completed) to make sure everything is still on track as development continues.
- Review individual team member status.
- Did you deliver on your personal responsibilities?
- Did you use your MSD II plan effectively? Was it realistic? If not already addressed above, what did you learn from this and how can you apply it to future projects?
The MSD II plan was fairly realistic, but progress depended on the completed design and testing of individual components. It took time to work through the best implementation of the h bridge circuits and test the striking mechanisms, but important milestones were able to be tested timely as well.
- Review your current risk assessment and problem solving status.
- Have you closed out your most important risks?
- Were there risks that you did not anticipate? If so, what do you think the reason is?
- Did any anticipated risks manifest themselves as problems?
- How did you use your problem solving process during the semester?
Most risks closed out, some longer-term risks not closed out due to uncertainties without long-term testing.
We seemed to do a good job coming up with risks, aside from anticipating the extent of disruption COVID would cause. Some risks like heating on the motors were anticipated but only appeared towards the end when the motor mounts and h bridges were in their final iterations.
There were some risks that became problems requiring redesigns or additional effort to resolve.
- Motor heating - resolved by resistors
- Beat programming board cost - redesign to webapp
The problem solving process allowed us to come up with and implement solutions quickly.
Deliverables Checklist and Website Status
- All documents must be uploaded to your website in advance of the Gate Review.
- The team should not use gate review time to conduct a detailed examination of specific deliverables unless related to discussion items in the status review.
- Is prototype hand-off complete, is the team's workspace cleaned up, and have all tools been returned?
Handoff was completed on 11/20/20. All tools were returned and cleanup of the workspace was completed on 11/24/20.
Lessons learned, etc.
- Does the team have any other lessons learned that were not addressed above?
- What advice would you give to future teams?