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

Big Blue Barracudas Cases

Big Blue Barracudasí Guide to M1

1. Forming a Team: How to find 3 people who can stay in the same room without killing each other
            By now you should have done at least one group project for this class, as well as in other classes. Remember who worked well in those groups and who didnít. Itís also a good idea to pick group members who excel in areas where you struggle. Canít add a button to a frame with both hands and a flashlight? Get someone who knows UI.

2. Identify Domain Classes: What to do when your Brainstorm is blocked by a high-pressure front
            A good place to start looking for domain classes is the project description, walk through it and look for nouns, any nouns. Donít worry about what does or doesnít make sense; youíre just looking for candidates right now. Once you have this list, start eliminating things that are either too specific or too general to be classes. Now add any other classes that you didnít come across in the description. You should be ready to start fleshing out your CRC cards (step 3 below) but youíll need to revisit your class list frequently. Donít be afraid to add or remove classes right up to the due date.

3. Making CRC cards: Not quite as fun as Pokemon cards
            Once you have a working list of classes, itís time to start making CRC card in preparation of role-playing. First a note on the physical task of drawing up the cards: we found the easiest way to get the cards made up was to just divide the candidate class list in 3 and each draw up the cards for the classes in our section. Once you have the Cards created, however, you may want to organize them according to their function before adding responsibilities. We found that having different people working on cards that were closely interrelated led to a lot of conflicts. For actually deciding which responsibility goes with which card, itís time to go back to the project description. Hopefully you chose your classes with some idea of what their responsibilities will be, but review the project description to make sure you didnít leave out anything major (donít get to nitpicky, the scenarios will help hammer out the details). Youíll probably find your self adding at least one or two classes at this point.

4. Scenarios & Role-playing: My level 15 2340 Student uses his +5 helm of Object Orientation
            Writing good scenarios is the key to not realizing that you need to scrap your entire design three hours before M3 is due. The first step is identifying the user for your scenarios. Who is he, what is he trying to do, and how should your program be helping him? Next, start thinking about how the user will want to use the program. The description will help here, but you donít necessarily want to follow the order in which the requirements are listed. Itís usually a good idea to start with a simple scenario and move to the more advanced functionality in subsequent scenarios. You should also have some continuity in your scenarios, so that problems in interaction between different parts of the program are more quickly apparent. Once you have your scenarios, itís role-playing time. Here youíll find the cards youíre looking for most quickly if each member is in charge of the cards whose responsibilities they wrote. Be prepared to revisit your class list and responsibilities frequently here. If you donít find anything to add here, youíre either the most amazing Software Engineers the world has ever known, or you have bad scenarios.

5. Meeting with your TA: How many points would you give Mr. Ben Franklin?
            Schedule your meeting early, so you can be sure of getting a time that most of all of your groups can attend. Thereís nothing worse than trying to explain what someone else was thinking when they created the ďWeaselĒ class for your database application. Pay attention to your TAís feedback during the meeting. You may not agree with him, but he knows how your project is going to be graded, so itís at least worth considering any suggestions. DISCLAIMER: We do not actually advise attempting to bribe the TA. This approach is entirely to expensive.

Link to this Page