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

Summer 2005 Milestone 3


This time you should take the time to do a careful design for the rest
of the system that you know about – that is, for M4. 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 20% 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, and we want to see what you come up

Your design will surely change over the following weeks, but we want
to see that you've gone through the process and made a plan up front.


Make a plan! The following pieces must be included, but otherwise
it is free form.

Specification for Two Denizens

You must include a description of your two new denizens. Write down
enough information about what they do that you could hand it to a
random software team and have a reasonable expectation that they
implement what you wanted.


You should write scenarios that touch on all major functions of the
assignment, including Milestone 2, from the user's point of view. See
About Scenarios.

CRC cards analysis

You should turn in photocopies of your CRC cards from your OOA for M2
and M4.

UML class diagram

Turn in a class diagram of what you plan to implement. You may use other
UML diagrams in addition to class diagrams if you want to further plan
and describe your system.


Remember the design criteria you have seen already:

Some of these rules are contradictory. Strive for a balance
between them.

Make sure that your scenarios are all covered. Step through each one
in your diagrams the way we did with the VCR example in class.

Test Plan

Your test plan should describe how you plan to check that your system
works. You should include tests based on blackbox test criteria. You
should document when and how you will perform your tests. Not all of
your tests need to be SUnit-based – be creative.

See About Test Plans.

Team Member Responsibilities

Write down what each team member is going to be responsible for. Be
thorough. Can you tell who will implement which classes and methods
from your class diagram? If something fails, will you be able to
figure out whose responsibility it was?


You should have a group timeline. It should include when you will
finish each piece of functionality. Don't forget to schedule time for
group meetings and for integration. You might consider
scheduling group hack sessions.

Cover Page

The easy part. :) Please include on your cover page:
  1. the group's name
  2. your TA
  3. the team members, including their gt#
  4. what milestone this is for


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.

Double check the list so that you don't leave anything out. Many
groups lose 10 points here and there because they left out a component


Link to this Page