Table of Contents
MSD I: Readiness to move to Build & TestOur team performed a self-critique before the end of the semester. And our largest takeaways were that we have spent a lot and done more time on theoretical work than we should have and we need to get started on actually developing software in order to start encountering problems and determine feasibility of completing the project by May 2018.
Status ReviewCurrent state of the project
At the end of the semester, we realized we were behind on the development of the model. We had originally planned on being done or almost done with the model at this point in time but that is not the case. Our main reason for this is that we thought we should be gaining more insight to the system and how to model it rather than actually working on modeling it ourselves. We had only just started on making a simpler truck scheduling model to gain an understanding of how some of the systems interact. We are planning to actually get started with modeling the problem properly next semester.
Individual team member reflections:
- I think that I made a lot of progress on my responsibilities. I was actually able to start producing something that is usable. I am dissatisfied that it took me this long to figure it all out, but I am pleased in what I've learned.
- The plan that was created from MSD I was pretty vague, and this semester I definitely realized that there were a lot of things that I didn't know that I didn't know. But new plans are being specified as the project progresses.
- I don't think I personally achieved all of my responsibilities. I spent a lot of this semester trying to figure out how to manage a project of this type and I thought that I needed to spend most of my time managing the project and not trying to develop anything. I've realized that I need to be investing more time in to the development side of the project since that is what the whole MSD process is about.
- I believe my responsibilities were adequately achieved. A reasonable system architecture was developed and early prototypes adhered to it without issue.
Risk assessment comparison:
Most of our issues with being able to close out our risks stem from not actually developing the model and the supporting systems since the majority of our risks are planned to be avoided or mitigated which requires observing that those risks can even occur in the system after we have developed it. As the model and the rest of the system get developed, we should be able to start closing risks.
Review MSD II schedule:
- Work with Taylor to further develop the basic model
- Further research how to handle model specifics in pyomo
- Start identifying potential “UX-perts”
- Sign-Up process implemented
- API update to handle multiple objective functions
- Task monitoring page
- Complete basic model with all necessary “tools” and functions
- Add in the specific resident scheduler constraints, objective functions, parameters, sets, decision variables, etc.
- Request URMC data for current year
- Schedule user tests with URMC residents
MSD II: Project close-out
- Use this space to organize information for your review. Key elements are listed here
- 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 actual performance vs. requirements
(include snapshot of current requirements document here,
along with a link to the live document.).
- Performance vs. Requirements can be found here
- Requirements related to collecting metrics and generating multiple schedules were unmet because of time constraints. Prerequisites were not completed in time to allow for these modules to be developed.
- The final design is not a working product. There is still development that needs to be done on the model in order for it to be fully functional. The web interface could also use some more development to become more featureful and intuitive to use.
- Aside from several dollars being spent for materials for Imagine, we were successful in operating under budget.
- Dr Proano seemed satisfied in the learning we accomplished throughout this project. He echoed our assessment that beginning development sooner would have benefited the final product.
- Compare your current project plan/schedule to your
- The scope of the project definitely narrowed throughout the course of MSD II.
- Our schedule had to change during MSD II because tasks took longer than originally planned.
- Start early, fail fast, be very generous with time estimations.
- Review individual team member status.
- Liam Kalir
- I was able to deliver on most of the features planned for MSD II.
- In retrospect, being more involved in the other aspects of the project could have been beneficial.
- Taylor Blackwell
- I tried to deliver on my personal responsibilities, but I had a very difficult time producing functioning code. There were several moments when I thought that I had working code, but it turns out that my validation techniques were flawed. So even though my code was running, it was doing what I wanted it to do.
- The plan that was created ended up being flawed because when I did come to a roadblock, I had no idea how long it would take to overcome those. I stumbled through a lot of the coding and discovered a lot of knowledge gaps that I had along the way. Given the opportunity to do this project over again, I would have created pseudo code earlier to explain my thought process to an expert that could help me fill in some of my knowledge gaps.
- Daniel Fox
- I did meet my personal responsibility to complete the data input part of the system. However, I didn't get to the data output side of the project since we ran out of time. I didn't deliver on writing the model, but I did help Taylor debug somethings here and there. And The project didn't get to the point where the team needed an UX-pert.
- I definitely don't think I was effective in using my MSD II plan, but that's primarily from being loaded with 18 credits. The main thing I felt that was holding me back from being able to get more done was the lack of time I had every week. The main lesson I've learned from this is that I need to know when to stop taking on more projects or ask for help in how to handle my workload.
- Liam Kalir
Deliverables Checklist and Website Status
- All code is pushed to GitHub repositories.
- Completed this page.
- Presented work to representatives from Strong Memorial's and RGH's residency programs, and Dean Ornt, notes preserved here and here
Lessons learned, etc.
- Rapidly prototype! It's just software, so the cost of failing is low.
- Use your resources. Dr. Proano is here, on campus, talk to him.