View this PageEdit this PageAttachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

Cuthroat Trout Case

Cuthroat Trout

MileStone One

During Milestone one, our team had initially gotten together and thrown around classes and did the initial collaborators. It was good for us to actually meet together and discuss classes rather than breaking it up for individuals to do the work. Afterwards, though, we realized that we wish we would have spent more times in the scenarios and possibly started looking at the UML diagram a little earlier, as we later found out when designing our UML and Sequence diagrams that are scenario roleplays were weak in touching on the meat of our classes.

advice - Meet early with your group and get done early, if you can start working on UML and Sequence and see how it matches with your CRC Cards

MilseStone Two

In Milestone two, our team started to meet more often and even started coding before it was due. This was very beneficial in getting a head start on finding our design flaws. In this phase, it would have been nice to have had a final project that incorporated a more concrete archeticture design and trust boundaries. Seeing as how this project was simplified, our group never fully grasped this concept. As we started drawing our UML diagrams and sequence diagrams we started to see how there many changes that needed to be made to our CRC cards and scenarios.

advice - When thinking up Scenarios, look not only at your CRC Cards but at your UML and ensure you use proper design patterns to accomplish the needed goals

Milestone Three

Milestone Three is where our project journey took a turn in a major direction. After starting to do SUnit tests, we found many design flaws from our initial milestones. For instance, breaking up our phases ended up with bad coupling our the phases holding the same information leading to major refactoring. After sorting through these design flaws, our domain classes were finally starting to come together, making it much easier to implement the UI. One communication breakdown we had in this phase is that two of the people were coding UI and the other two were coding domain. One group was creating changes as were the other. Once we started to combine these classes, problems of coupling and backwards MVC arose. We learned in this phase to communicate more often what we were doing and in which direction data should flow.

advice - Start early on this if you can, don't be afraid to look back at UML and Sequence diagrams as you code. This helped us tremedously to find errors in our design which ended up saving us hours in the long run

Milestone Four

Milestone four was much easier than milestone three simply because we had, by this time, formed good communication skills and had our domain classes completed and designed well, and they were also communicating well with the UI. With such improvements in our program and teamwork, we actually finished quite early and had the opportunity to work on extra credit, where we quickly started to see the advantages of having a strong object-oriented design. For instance, adding the save project and UML algorithm was much easier to plug-in into our design rather if we had done more of a C programming style.

advice - This is a great point to test, if you get done early, adding Extra Credit to your code. If you've done good design, you will find this easier to accomplish. At this phase, it was extremely important for us to meet as a group to make sure the right things were getting communicated between the domain and the UI

Milestone Five

In milestone five, we were very limited in the screen mockups we could test, leaving us to look into the finer details of UI evaluation. While we spent more time trying to find UI flaws, it was a good learning experience to begin to see how small things can mislead and potentially frustrate a user. We really enjoyed seeing what the other team had to write about our project and we began to see the importance of UI evaluation as things were pointed out in our project that we, as developers, may have never caught.

advice - Print out homemade 'bug reports' where you right down anything and everything you see. Afterwards, then go through it as a group and pick out the big ones you would like to write about. When responding to an evaluation, open up your program and try to envision what they saw, not as the developer.

Link to this Page