Flat Circle Society Cases

• Start early and stay ahead
• Be proactive in communicating with your TA
• Try and find a good, distraction-free discussion place for meetings
• Use some kind of repository or file storage/sharing method (like Store); it may be inconvenient to set up at first, but as long as it’s used properly your repository will pay off in spades later on.

• Setting a couple of lengthy, consistent meetings aside to identify domain classes, create candidate classes and CRC cards helps. During those meetings, it is important for each group member to go through the project requirements and separately come up with a list of candidate classes to be discussed and merged together. After assigning role stereotypes and responsibilities to narrow down the number of classes, the role-play walkthrough helps make scenario design much easier.

• We may have begun developing our project without a proper understanding of what we were doing. For example, we lacked UML implementation in our cards. This also is partly because of the type of project we were making. A project for OOA/OOD design is difficult because of all the double meanings- do we make the project make a uml diagram or do we make a uml diagram of our project design.

• Long-term planning is a plus if it can be done. If your group intends to do extra credit, be sure to plan that into your initial design and concept cards. It serves to lay your work out for you early and if necessary, to cut it later.
• Meetings with the TA were not timely. If you are finding yourself hamstrung by not having your index cards in your possession, make sure to meet ASAP with your TA for feedback, if nothing else.

• We were somewhat timely in setting aside enough time.
• We were all able to sit down and discuss our decisions as they came up.

• Paper UML diagrams are hard to correct and without them a group is practically stopped in the water. Use UML software (Visual Paradigm, Poseidon, etc.) to do your diagrams; they are mobile, presentable, and easily modified. This also goes back to the meetings with the TA were not timely. We did not get back our paper UML diagram until after M3 was due, and had nothing to code from.
• Communication and finding free time are difficult. Be sure to make this a priority, as this milestone is as important as the code-heavy milestones that follow.
• We underestimated the importance of the design phases, a mistake that became painfully obvious in the next two milestones.

• We needed to have started more meaningful code by the due date. Professor Waters recommended that groups be “well-into” the code-writing process during the period between M1 and M2. We were barely into the mock-up stage.
• We needed more knowledge of Smalltalk/VisualWorks to really get up to speed.

• Up against the turn-in deadline, we were able to hash out something we could turn in.

• Too laid-back: through a lack of proactive action or expecting to be notified about when to pick up our cards, we were hamstrung by having to basically reconstruct our project from memory.
• Convenient meeting times were hard to come by and it contributed to our group falling behind somewhat.
• Testing implementation was last-minute and not properly done, though it was a minor mistake that could have been unearthed with more time.

• Do not spend thirteen hours in a row on turn-in day trying to finish even a skeletal set of requirements. You will be worn out and you are likely to have major problems in your next milestone, as being this far behind will mean things were either not implemented or functionality was overlooked.
• Virtually all of the required implementation for this project (except for the UML and implementation phases) was done in this stage; it was a painfully difficult load to bear.
• Again, be sure to meet with your TA, and if possible, run code ideas and UI ideas by your TA. It will save you pain and getting another opinion will help on the usability/HCI side of project design.

• We were able to tie up most loose ends that were left undone in M3 by the time our demo time came.

• We were up against the deadline fixing bug-plagued code that still lacked a significant amount of UML implementation; it’s fair to say that we were more busy doing M3 work than M4 work.
• Without a lot of time to meet, we were stuck with a single session on turn-in day.
• Because we were so behind with M3 implementation, scenario role-play went untouched in M4.

• Timing: even with the extension, the Thanksgiving holiday negated it, as feared.
• Communication: given the Thanksgiving extension, be sure to try and keep in touch with your teammates and actually try to accomplish something during the extension period.
• Be sure to divide work. If not, be sure to publish working code when it’s working so that teammates do not create additional problems in stacking implementation on top of that code later.

• We learned a lot about the HCI procedures, a benefit for the final exam.
• Our team came up with a critique matrix to analyze the other team’s demo. This made our work incredibly straightforward.

• Poor communication was prevalent in this phase. It seemed that only two people were really needed to go through and analyze our feedback matrices, and to get things done, some of us split off to work on adding M4 functionality while others worked on the M5 evaluation.

• We could have spent more time meeting to discuss our responses than we did, but it didn’t seem to be a huge issue. Our matrix made up for much of our analysis.

Link to this Page

• Cases last edited on 30 July 2011 at 2:33 am by r59h132.res.gatech.edu