Design

Draw a class hierarchy.  If you can't or the resulting diagram doesn't
make sense to everyone on the team, you shouldn't be coding yet!

Some documents weren't detailed to the level of describing (at least
the important) public methods of each important class.  You should not
go very far with implementation until you make these decisions.
Otherwise, you run the risk of wasting a lot of implementation and
debugging time.

Decide on class vs. instance, method vs. member var., public
vs. package vs. protected vs. private, etc. before moving on to
coding.

Development Strategy and Timeline

Identify at least one subset of your features or functionality that
would result in a running implementation (even if it's a little scaled
back).  By making this subset version of your project an early goal,
you can better ensure that you get something done on time, even if
unexpected problems arise.  The (undesirable) alternative is to end up
with a bunch of classes that don't integrate into a running (or worse,
compiling) program.  

For those w/ networked applications, especially those with
"peer-to-peer" architecture, take care not to get too ambitious unless
you have prior experience developing similar applications.  Even with
a client-server architecture, you should make sure to identify useful
subsets, perhaps even one early milestone version that isn't actually
networked.

Consider using "pair programming" practices to ensure everyone
understands how the project is developing.  Choose a "pilot" and
"co-pilot," with the co-pilot at the keyboard focusing on lower level
details, e.g., style and syntax, and the pilot focusing on higher
level issues, like sticking to the planned design, interaction among
classes, etc.  The goal is for both of you to be actively involved the
development for better decision-making and understanding of how it's
proceeding.

Make sure to look at each other's code as you go, esp. if you've
decided to divide development of the code among team members.
Consider "swapping" responsibilities to do unit testing.  So that we
all learn from the experience, each team member is expected to
have a basic understanding all of the code in your project.  Make sure
to support each other in achieving this goal.

Don't wait to start the report.  As part of it, you're expected to
discuss a design decision, so I strongly recommend you jot down some
notes as you run into your more difficult/contentious design
decisions.  This is where *real* engineering takes place, and this is
what we'd like you to discuss, esp. with respect to how your decisions
are affected by the language you're using.