






Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Flat Circle Society Cases
Overall suggestions
- 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.
M1:
• Form a 3-4 Person Team
• Identify Domain classes
• Create CRC Cards and Scenarios for the Candidate classes
• Assign Role Sterotypes and Responsibilities to classes
• Roleplay scenarios to clarify responsibilities and collaborations
• Meet with your assigned TA (after submission grading) to discuss your design and possible improvements
What worked?
- 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.
What didn’t work?
- 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.
What could have been better?
- 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.
M2:
• Create your Software Architecture and Trust Boundaries
• Identify your Application and Utility Objects
• Add necessary CRC Cards and any new scenarios needed
• Submit a UML Class diagram of your refined design
• Submit 2 UML Sequence diagrams that shows your full design handling one or more scenarios
• Submit screen mockups that show your preliminary user interface. These screens can either be hand-drawn, or prototyped with the VW Painter and then captured.
What worked?
- We were somewhat timely in setting aside enough time.
- We were all able to sit down and discuss our decisions as they came up.
What didn’t work?
- 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.
What could have been better?
- 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.
M3:
• Implement Domain Objects
• Implement basic UI screens to input data
• Create SUnit tests to unit test your core Domain Objects
What worked?
- Up against the turn-in deadline, we were able to hash out something we could turn in.
What didn’t work?
- 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.
What could have been better?
- 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.
M4:
• When a scenario is selected for roleplay, the cards display graphically on the screen, and arrows move from responsibility to responsibility showing the flow through your classes.
• When a UML diagram is requested, display a simple UML diagram showing the classes, and their relationships (limited to inheritance or basic association).
• There is no requirement for fancy layout support.
• There is no requirement to support full UML (interfaces, aggregation, etc.)
What worked?
- We were able to tie up most loose ends that were left undone in M3 by the time our demo time came.
What didn’t work?
- 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.
What could have been better?
- 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.
M5:
What worked?
- 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.
What didn’t work?
- 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.
What could have been better?
- 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