Let me start somewhere close to the beginning of the semester for this story. Our group picked the “Patient Database Administrator” project, thinking that we would be building a full tool for docs to access all their patient records. Yes, in retrospect that sounds too HUGE to be able to do in a single semester, but that’s what we were thinking. We then, before meeting with our client, found code that a previous group had built for this same project, and assumed they were related. At this point, it is 2-3 weeks into the semester, and we still haven’t had an opportunity to meet with our customer!! Once we finally did (for 3 HOURS on a Friday night!!), we managed to make clear the purpose, goals, and scope of this project: create a custom form generating engine that our customer can plug into their overall tool to take all patient records and forms online (including managing the hospital as well).
This project description is of smaller scope than even by the end of that meeting, but we managed to make it more concise over the following weeks, which was nice. Let me describe our customer for a moment though. He is a big-thinking Neurosurgery doc who is finishing up his residency (in the final 2 years I believe) at Emory University Hospital. When I say big-thinking, I mean he sees the big picture very clearly, but doesn’t see all the little steps to get there at the same level as the people he has gotten to accomplish them. This lack of seeing eye-to-eye on many of the technical matters means that we senior design groups receive emails that regularly change, or attempt to alter, the direction we are headed with this project. Some examples include the frameworks we are using have been changed multiple times, typically with more added rather than our overall structure being simplified, and our technology choices were limited to some proprietary software (Flex, which is Flash) that we have to use FREE TRIALS to be able to code in for 60 days. Don’t get me wrong, Flex will likely make coding the front end a lot easier, but that doesn’t mean that it will make our lives easier as a whole since we have to use a framework called Mate with the Flex UI… it’s basically a wreck right now with us trying to put together enough pieces that we can get things rolling so that we can meet deadlines. A minor detail to add, being asked for working prototypes when we haven’t been able to get any real coding done yet, and being asked for the same documentation that has already been sent out, is really annoying from a team managing perspective. Really doc? I sent you those docs about 3 weeks ago!!!
Anyway, we have a lot of work ahead of us. Here is a quick breakdown of the technology limitations and our deadlines for production:
- Java back-end
- Hibernate to communicate with the DB
- Flex UI
- MySQL DB (ended up being the better choice out of the options, we got lucky here)
- Start of semester: 8/23
- Picked project: 8/29
- Met with customer: 9/10
- Met with DB professor on campus to discuss our design (and he loved it by the way): 9/24
- Documentation due date and group presentation to class (end of Sprint 1): 9/27 — we were supposed to have started coding at this point, but didn’t have the time because we met so late with the customer and had so much documentation to do in the limited amount of remaining time for Sprint 1.
- Upcoming, end of Sprint 2: 11/1 — we plan to have a prototype in place by then, but feel woefully behind because we had so much trouble setting up our local development environments. Really cost us on time!
So we have time to get things done, but are going to have to really push it the next 2 weeks to meet our planned deadline for a working prototype.