Sam Brunjes, Patrick Harrison, Kramer Sharp
Grahame Burke, Richard Hsu, Michael Lew, Mike Liu
Emily Lam, Rachel Phillips
The project has several deliverables spread over the remainder of the
semester, leading to presentations and demos on the last day of class.
Details on some of the deliverables are below (more details on the first
three deliverables are included in this document below).
- Friday, October 27 (before 11am) — team requests due
- Wednesday, November 1 (beginning of class) — project idea description
- Friday, November 10 (beginning of class) — project design document
- week of November 13 (scheduled by teams) — project design reviews
- week of November 27 (scheduled by teams) — project progress reports
- Monday, December 4 (in class) — project presentations/demos
- Tuesday, December 5 (before 5pm) — project final reports
including code and teammate assessments
Collaboration Policy (read carefully)
For this project you will work in assigned teams. If you have
preferences about who you work (or don't) work with, send them to me
before 11am on Friday, October 27. Teams should be at least two
students, and no more than five.
You should divide work among your group members in an efficient and
fair way. It is not necessary for everyone in the group to work
together on all parts of the assignment, but every student should
contribute equally to the work.
At the end of the project, each member of a team will be expected to
submit a teammate assessment form, rating all of the team members'
individual efforts and contributions. In most cases, all team members
will receive the same grade. Team members may receive different grades
if it seems clear that they did not contribute equally to the project.
Instead of regularly scheduled lab hours, teams will also be assigned
one of the assistant coaches as a "consultant". You should view your
consultant as a highly paid expert (you needn't actually pay your
consultant, of course, but giving them Bodo's or Krispy Kreme's is
encouraged) who can help a limited amount with your project. You
shouldn't expect your consultant to implement part of your project, but
you should use them as a resource to help with your design, and to help
with tricky parts of the implementation.
- Learn to design, build, and validate a (reasonably) complex
software project from start to finish.
- Demonstrate your ability to apply ideas from this course to
developing a software system.
- Gain experience working in a team.
- Hopefully, build some useful software that you team members and
other people will actually want to use.
Your project can be anything you want as long as it is small enough for
you to complete by the end of the semester, and complex enough that your
successful implementation will demonstrate your understanding and
ability to apply key concepts from cs205 including procedural
abstraction, specification, data abstraction, inheritance, modular
design, and systematic testing. You may implement your project using
any languages and tools you want.
Ideally, your team will develop and idea for your project that will be
(1) something that all teammates agree is an interesting project to work
on, and (2) lead to a software system that you and others will find
useful enough to want to keep using (and developing) after the class is
Some of you might consider developing a Google Gadget or a
web application so your project may be more readily used by others, but
it is also fine to develop a stand-alone Java application or a Java
Since your project will involve several files, and your team will need
to ensure that multiple team members do not simultaneously edit ths same
files, we recommend using CVS to manage
your project files. This will allow your team to store all your project
files in a shared repository, and team members can check out and edit
the files you want to modify. CVS will check there are no conflicts
when files are updated. See the CVS guide for
information on CVS.
Project Idea Description
On Wednesday, November 1, bring to class a short description of your
project idea. It should describe what you plan to build from a user's
viewpoint — what will your program do, and why would someone want
to use it? You should also have some preliminary thoughts on how you
will build it and what the main challenges will be.
Project Design Document
On Friday, November 10, each team should turn in a project design
document. It should contain:
- A description of your project: what it will do and why it is
useful, fun, or interesting.
- A high-level description of your design, including a module
dependency diagram showing the most important modules.
- A description of your implementation and testing strategy including:
- how you will divide the work amongst your team
- how you will order the work to support incremental development
- how you will do unit testing and integration testing
- a list of milestones and a schedule for achieving them, leading to
a completed project on December 4
- A list of questions