Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
The Band Greeks Cases
Team Band Greeks Case
Overall, as with most projects, we could have improved our program.
What worked:
- We managed to implement most of the design we planned out. Our pre-planning process was thorough enough to not need many changes when we started writing code.
- Goal feature was complete and goals could be added by the user.
- Candidate class feature was fully functional, where users could brainstorm classes and make final classes with CRC cards from the list of candidate classes, and also delete them
- CRC Card function worked. User could view created cards made in the candidate class feature and add responsibilities and collaborators, stereotypes, and roles.
- Scenario function worked well. User was able to create scenarios and add steps to them, which were tied to responsibilities of whatever CRC Card they chose
What did not work:
- The UML diagrams- we got the boxes with the class names to generate, but did not get the associations to show up
- The Role-play diagrams- this never ended up getting implemented
Some changes that were made to initial design:
- CRC Cards were initially going to be implemented using tables but we did not have enough knowledge of how tables would work so lists were used instead. We were going to have combo boxes inside of the table where you would select the collaborators but that was becoming a bit complicated
- Scenarios Steps were also going to be constructed using tables where you had the name of the step in the first column, the collaborator in the second column and the responsibility in the third column. Again we did not have a thorough understanding how tables worked so lists were used instead.
What could have been different:
- We really should have met together more times, but our schedules conflicted a lot. Also we were all in band and did not have much weekend time.
- We originally planned for a very complicated GUI, since nobody knew just how hard GUI is in Smalltalk. We should have done some research on the GUI first and seen what kind of restrictions we would have, and start off with a simple prototype for the GUI. This would have made it easier to add more complicated GUI later on. As the project progressed, we tried to stick to our original designs, but many changes had to be made, and the GUI ended up not being as consistent.
- We could have split up the work in a different and fairer way, because the person that got stuck with the GUI had to spend a lot of extra time trying to figure out how it worked. If we had done that research and learned basic GUI stuff, we could have split the GUI up and it would not have taken so long. Then maybe we could have actually finished the entire project instead of running out of time.
By milestones:
M1 went well. Ended up having to add a few more classes in M2.
M2 was good for the most part; however we had done our scenarios completely wrong and had to redo them. This was where the GUI mockups were designed, and they should have been simpler and easier to implement.
M3 was pretty much completed. There were a few errors and a tiny bit of the functionality was missing.
M4 was when we fixed everything from M3, but ended up only adding half of the rest of the functionality for this milestone.
M5 was educational!
Links to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu
- The Band Greeks last edited on 7 December 2006 at 10:10 pm by c-76-17-114-252.hsd1.ga.comcast.net