Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Team Animaniacs Cases
Edit Team Animaniacs Cases here.
What worked: Since there were four people, having everyone brainstorm individually before coming to the table to defend their ideas was an excellent way to start the design process. This way everyone had a chance to have input and we had a variety of different choices for each decision. This is also due to all four people having different background. Some had advanced design knowledge and some were excellent at coding/implementation. This means that we looked at every decision from a designer and programmerís point of view. We also met up and talked through everything. We had a class for every possible object we could need.
What didnít: With four people looking at the huge list of classes we initially had we needed to cut down but had some trouble deciding which ones. When you start looking at the list of stereotypes and all your classes you start feeling like each class is all of the listed stereotypes. Especially with all four of us picking different ones and having valid reasons for our choices. We got very confused.
Hints: Try and meet with the TA/Instructor to get a clearer understanding of what the roles/stereotypes for classes should be. Sometimes they can be more than one. But certainly every class in you design shouldnít be all of them. TAís know what the basic design should be and can suggest changes that will make you gain points that you may have lost without talking to them.
What worked: Since the whole group agreed upon our design decisions and modifications from the original we split up the work evenly and worked on it at home. This made it easier for all of us since half the group lives a fair distance away from campus and we all had different schedules/priorities.
What didnít: Since we split up the work, we did not have enough time to collect everything, put it together and meet for the TA for any possible advice.
Hints: Make sure the whole group is on the same page for the whole design including the smallest details. This way many mistakes can be avoided since the UML and CRC cards can be quite tedious. The Screen Prototypes should also follow the design.
What worked: Having a team member that was really motivated by Smalltalk no matter how much they initially hated it.
What didnít: Having team members lose touch. Even with phone numbers and e-mails half of our team somehow disappeared at crunch time. This left most of the burden on our own coding expert. J Even at our meetings not much was accomplished, as our team was a little too laid-back.
Hints: Make sure that everyone has a part of the project that they feel they will excel in. With our team our coder did most of the code and the HCI specialist did most of the usability part.
What worked: Having an expert coder and a thanksgiving break extension.
What didnít: Having two people disappear essentially.
Hints: Communication is essential. ALWAYS, ALWAYS keep in touch with your group!!! It is hard to make group decisions with out the whole group. The two people who did the work felt like it would only be fair to give the rest of the group a chance to suggest changes in our work. This meant getting it done before the day the assignment was due.
What worked: having an HCI specialist on the team. Also, having people evaluate the prototype using the cognitive walkthrough that were not part of the class. This gives the evaluation a more realistic result. We had a wide variety of users.
What didnít: Sometimes focusing on functionality of the program and not usability. Usability is the only issue that matters in M5.
Hints: With every step of the way through M5 make sure you double check to insure that you are considering Usability and not Functionality. Maybe ask a person who is not in the class and has CS knowledge. It is easy to want to determine usability from the program errors etc.
Link to this Page
- Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu