Table of Contents
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: Readiness to move to Build & Test
- 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 ReviewCurrent state of the project
- Summarize expected performance vs. requirements (include snapshot of current requirements document here, along with a link to the live document.)
- Address any issues raised during your Detailed Design Review.
Issues that have been addressed and the team is closing them out before next semester are highlighted in GREEN. Issues that have not been addressed yet, but the team has a clear path to a solution to close out by week 2 of MSD II are highlighted in YELLOW.
- Compare your current project plan/schedule to your
- Has the scope of your project changed?
- How and why did your schedule change?
- What have you learned from these changes?
- 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
- 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?
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.
MSD II: Project close-out
Final Project Documentation
|Project Management||Design Tools||Design Documentation||Implementation||Validation||Presentation & Dissemination|
Status ReviewCurrent state of the project
The jumper now has increased the number of switches available for the baby to interact with from one to five. Each switch initiates a unique light pattern in the main base and toys. These ten LEDs are an increase from the original three. The main platform on the jumper now offers 4 levels of volume control over the song playing, ability to switch between two modes (continuous play and interactive), and next track selection. It also includes provisions to allow for pause/play control on the app.
A video of the jumper functioning using the controls on the main module can be downloaded here.
Below are pictures showing the electrical components that are now contained within the main module of the jumper:
Below is a screenshot of the app user interface:
A video of the jumper functioning using the controls on the app can be downloaded here. In the video, it can be seen that changing the top slider affects the volume at which the song is playing on the jumper. Next, the video demonstrates that the second slider can control the brightness of the LEDs when buttons are depressed. Lastly, the pause/play button is pressed and you can hear the song stop the resume when the app button is pressed again. The "Next Track" button was experiencing bugs so that is not reflected in the video but it is functioning at the completion of the design review.
A video of the accelerometer data being live displayed on the app can be found here.
Performance vs. Requirements Summary
As seen above, the only test plan that did not pass was the one testing for our power consumption requirement. The reason this test result did not perform to desired/expected specifications is due to the team's choice to switch audio modules. Originally, a low-power solution was anticipated but this solution would have required a lot more development work that the team did not have time to complete. Instead, a different sound module solution was chosen to save on development time in order for the team to have a working prototype in time for the end of the course. This solution is not nearly as efficient with power consumption and would need to be replaced with a lower-power component in the future in order to meet this engineering requirement.
Final Budget Use
Below is a diagram of the team's expenses and how they were distributed across purchase categories.
Engineering Standards Considered
Our product falls within ASTM F2012 - 16: Standard Consumer Safety Performance Specification for Stationary Activity Centers. The document describing theses specifications can be found here.