Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Sum2003-M3: Design Everything
Goal:
Plan, Analyze and Design the Entire System
Team Forming:
For M1 and M2, we limited the scope of certain operations and made parts of the system somewhat artificial. For this milestone you will need to form a group of 3-4 students from within the class. This group will be responsible together for milestones 3 through 5. Your first task for M3 is to form your group, and create a team entry on the Swiki in the Summer 2003 Team Declaration Page. YOU CANNOT DO THIS PROJECT ALONE (or in a 2 person group)!! You may reuse any code that you wrote for M1 and M2 if you feel it is useful. The only restriction is that the M1/M2 code reused must have been written by one of the group members in your group.
Milestones to come:
Look across Milestones 4 and 5 which are your actual programming milestones. Along with the information in this milestone, you should then have enough information to design the entire system. Each milestone represents the LATEST time that functionality can be provided. At each milestone, we will only grade the functionality required to be present at that milestone. Basically you can view milestones as your latest acceptable delivery date.
Side note: You may, of course, create the desired functionality earlier if it will help your project succeed.
At each milestone we will quickly regression test your old code to ensure you have not broken anything. If you want, you can use SUnit (see SUnit lectures from Spring). This is where SUnit can really help you. By having unit tests already coded, you just hit the run test button and verify that your test bar is still green. Whenever you find a "bug" in the system that was not caught by SUnit, you should add an SUnit test that would have caught it. That way, you can be sure that old bugs do not get reintroduced into your code base.
Note about CVS:
There is no requirement that your team has to use CVS or any other version control system. Configuration control systems do make code exchange and work easier. I do recommend you look at using CVS with the Squeak interface DVS as a good way to work with your team in controlling and exchanging code.
Description:
The system description is much more open ended that M1 and M2. You may design your classes and messages however you desire to meet the basic requirements of the system. Just keep in mind good smalltalk style for message names and overall design principles. Your design is worth half your grade for the milestone, so don't hack and don't shortchange your analysis. If the requirements do not specifically state something, you are free to implement and design however you want. This is a design class, we want to see what you come up with!
Ask Questions on Summer 2003 M3 Milestone
Teams must turn in a detailed group plan THROUGH THE REST OF THE CLASS (i.e., through M5) . This should include:
- SCENARIOS that touch on ALL IMPORTANT FUNCTIONALITY in the program and which touch EVERY CONCRETE CLASS IN YOUR SYSTEM.
- CRC card analysis for ENTIRE system (through M5).
- UML class diagram for the ENTIRE system, plus DESCRIPTIONS for all classes. You may use any other UML diagrams in addition to a class diagram that you would like in order to describe your system.
- description of the RESPONSIBILITIES for each team member
- Internal group TIMELINE with dates and milestones
Each team will submit a joint document with cover page. The cover page should show the team name, the team members by name and gt# and their grading TA. It should also have the date submitted and the Milestone number clearly shown.
Obviously, the design will change over the following weeks, but we want to see that you've thought through everything UP FRONT.
Note: If you would like to see good examples of project plans, check out the Cases page to see what other groups in past semesters have done.
Turnin your in your hardcopy designs in class.
Grading:
- 20% Good, believable scenarios that account for all major functionality and that touch on every class in your design.
- 20% Good CRC Card Analysis: Reasonable names, understandable and clearly defined responsibilities, good exploration of other class names
- 20% Good UML class diagram and descriptions:
- Correct usage of notation (10%)
- Detailed and understandable descriptions and names (10%).
- 20% Quality of the design
- 10% Clear definition of team member responsibilities: Can you tell who will do which pieces of system (as defined in UML and descriptions)? Will you be able to figure out whose part failed if there's a failure?
- 10% Believable and detailed group timeline: Could someone figure out from this what they're supposed to be doing each week? Can a team member figure out what they're supposed to have done each week from this?
5% extra credit for a team meeting with your TA to discuss and review the design.
Links to this Page
- Summer 2003 Project Milestones last edited on 8 May 2003 at 3:11 pm by user-11fa82t.dsl.mindspring.com
- Cases Page last edited on 25 July 2003 at 7:45 pm by conway-w2k.cc.gatech.edu
- Group No. 9 last edited on 27 July 2003 at 9:58 pm by r57h176.res.gatech.edu