The Assignment

For the final project in this course, you will work with a group to write a multi-layered community of communities. This handout contains some specific suggested projects, but you may come up with any project that you wish. Whatever project you choose must meet certain criteria:

• You must have a user interface, preferably a graphical user interface. You may use any of the GUI classes built in to Java or those that we have introduced during the semester.
• You must have (at least) two separate entities running in two separate spaces. For most of you, this will mean applications running on (at least) two separate computers, perhaps using a centralized server architecture. Two or more applications running on a single computer or even two or more applets running on the same page would be acceptable alternatives.
• You must explicitly build the connection between these entities, e.g., using Sockets or other Java standard classes. In particular, you may not use the ClientWire and ServerWire classes to establish a connection between these entities, although you may use ServerDialog and ClientDialog to facilitate runtime collection of connection information.
• It must be possible to complete the project that you have selected in the time allotted. Final judgement on whether your project is viable rests with the course staff. If you plan to do a project other than one that we have suggested, you should talk with a course staff member about your plans as soon as possible.

You may reuse any of the code that we have given you, except for the Wire class. You may also use other publicly available code under the terms of usage with which that code is supplied, provided that you meet the criteria outlined above. As always, you must acknowledge any sources that you use. Unacknowledged use of others' code is a form of intellectual property theft.

In addition, each teammate is expected to add some original code to your project.

Some suggested projects that are appropriately sized are:

1. Extend the Scribble project by modifying the underlying ScribbleData to communicate over a network. Make this a multi-user collaborative drawing program. Perhaps add text communication.
2. Build a multi-user chat program with individual log-ons and both private and public communication channels, like IM and chat.
3. Extend the Cat and Mouse game available on the cs101 website to multiple players and/or significantly enhance the two-player game. Note that you must replace the Wire-based communications with your own network connections.

Past students have built a variety of networked video games. There are also numerous potentially useful web services that the Olin community might benefit from. You are welcome -- even encouraged -- to come up with your own ideas.

No matter what project you choose, your project must be approved by 8 April. Realism (and a good staged development plan with appropriate worst-case planning) will be a major factor in project approval.

Timetable

This project has several interrelated aspects with a variety of due dates. You are responsible for designing, implementing, documenting, and presenting your project to the class. The schedule for this project is summarized below.

Team Selection

In this project, you have two choices. You may select a group of teammates yourself, or you may ask us to assign you to a team. A team should be no smaller than 2 and no larger than 4. If you wish us to assign you to a team, you need to let us know by 6pm March 31 at the absolute latest. (Talking to us in lab is a viable option :o) )

Also, if you organize your own team but would like an additional member, please let us know by the same time.

Team Registration

Whether you organize your own team or are assigned to one, you should be prepared to provide the following information in class on Thursday, April 3:

• The names of your team members.
• The name of your project. This may be used as a group directory name.
• Whether you plan to do one of the suggested projects (or a minor variant thereof), in which case you do not need preapproval, or what your alternate project idea is, if you wish to do a different project.

Lab Structure

The labs during the first three weeks of the project -- April 7, 14, and 22 -- are required project conferences. You will need to sign up for a conference appointment at which all members of your team must be present. We will use these conferences to check your progress on your project and to help you replan as necessary.

In addition to the project conference, you are free to attend any lab sessions that you wish or to work on your project entirely outside of scheduled lab hours. We may announce additional office hours/open lab times or you may certainly request a specific meeting/check-in time.

As always, you will need to build and test your software. Keep a careful record of the work you do so that you will be able to include it in your project writeup.

First Week Lab: Project Proposals

Prior to lab on April 7 (specifically, by 6pm on Sunday April 6), you will need to email a project proposal to las. You should bring this (on paper or electronically) to your project conference as well. This proposal is described in detail below.

At the first project conference (and each subsequent conference), you should expect to make an oral presentation. You should plan for this to be 5-10 minutes, with lots of questions to follow.

Second Week Lab: Checkpoint 1

During the second week's lab, you will need to present your project as it exists at that point. Ideally, it should meet the criteria you developed for the first checkpoint. You should also identify any issues that have come up so that we can discuss them and brainstorm their debugging.

Again, expect to make a formal presentation for 5-10 minutes, with lots of questions to follow. You are not expected to provide any material in advance of this meeting, but that of course means that we won't know anything that you don't tell us.

Third Week Lab: Checkpoint 2

Note that this lab is on a Tuesday, though it's an Olin Monday. At this checkpoint, your project should ideally be exhibiting the minimal complete functionality that you designed. You should expect to spend the next week cleaning up and document your code, preparing the user's manual and poster and putting together a final project presentation.

Again, expect to make a formal presentation for 5-10 minutes, with lots of questions to follow. You are not expected to provide any material in advance of this meeting, but that of course means that we won't know anything that you don't tell us.

Fourth Week Lab: Peer Demos

In this lab session, you will provide a project demo for (some of) your classmates. You will also be asked to provide peer evaluations for your labmates.

At the beginning of your lab session (or earlier, if possible), you should set up one or more computers running your project. Alternately, if your project is easily run from a generic student laptop, you may simply provide instructions for how to set it up. In addition, you should provide four copies of a self-explanatory user's manual of 1-3 pages as well as a (marketing and/or technical) poster for your project. Note: You will not accompany this demo; you will be otherwise occupied while students try to use your project, so be certain that it's reasonably standalone.

During your lab session, you will be playing with other student projects. In particular, you will be asked to try out between one and three projects and to evaluate each of them on the following criteria:

1. Usability of application.
2. Clarity of instructions.
3. Interestingness of application (including utility and fun as appropriate).
4. Functionality of application (including robustness, features, etc.).
5. Apparent design of application.

A specific rubric will be provided.

Project Proposal

In lab on Monday 7 April, you will make a formal project presentation. We will schedule presentation conferences in class on Thursday 3 April. Your entire project group is expected to be present at this meeting. This is, in effect, your check-in for the final project.

Proposal Writeup

You should submit electronically by 6pm on Sunday 6 April a (single) project proposal document. This document must contain the following information:

1. Your team members' names.
2. Your project title.
3. A description of your project, specifying in some detail what the scope of the project will be.
   1. This includes the minimal functionality that you will certainly build, which should in your estimation be doable in approximately two weeks.
   2. It should also include additional functionality that you will add -- in steps, testing each one as you go, always maintaining a copy of the last working version -- that you will add as time permits.
4. A development plan and timetable.
   1. What are the various stages that you will implement, and by when will you complete them?
   2. How will you divide the work to be done? What role(s) will each of the team members play?
   3. You will need to specify an intermediate checkpoint to be demonstrated at the first project checkpoint on 14 April.
   4. You may choose to further specify specify the second checkpoint to be demonstrated on 22 April. Otherwise, the expected behavior at that checkpoint will be the minimal functionality.
   5. Don't forget to allow time for testing, debugging, code cleanup, documentation, and preparation of the presentation, user's manual, and poster.
5. If your project is not one of the suggested projects, you will first need to describe it and then explain how you will build it, etc., as above. Remember that any non-standard project ideas must be submitted (in the form of a brief description) by class on Thursday, April 3.

Your writeup should be between two and four pages in length. Only one proposal writeup is due per team, but the writeup should reflect a collaborative effort.

Oral Proposal

You will also need to describe your project in person at the first project conference. This description should be a team effort. It is, in effect, the check-in for the final project, although you do not need to complete this step before beginning any work. Check-in criteria include a solid understanding of your project and the components involved, a sensible development plan, and a reasonable division of labor. Each of your team members should be prepared to answer questions during the project presentation.

Also at this meeting, you should agree upon an intermediate checkpoint to be demonstrated during the second week of lab.

If there are concerns raised at this presentation meeting, you may be asked to revise your (written) project proposal by the next day.

Demonstration and Presentation

As described above, during the lab on 28 April your project will be available for demos. In addition, in class on Tuesday or Thursday of that week, you will give a 5-10 minute presentation and demonstration of your project, followed by a brief question and answer period. This presentation should include a demonstration of the major features of your project and highlights of its functionality. You can think of this project as a marketing presentation, though it is fine to go into technical details. Handouts are acceptable but not required.

We expect that these presentations will be prepared, rehearsed, and polished performances. Expect to spend several hours putting together the presentation and any accompanying materials. Practice your presentation for your teammates and friends, or perhaps in front of a mirror. We may ask you to dry run these presentations during lab on 28th.

All teammates should participate in the presentation, though you do not need to give each teammate an equal amount of airtime.

Presentations will be evaluated by your classmates as well as by the course staff. You are responsible for attending and evaluating all of your classmates' presentation.

What you should turn in

Your project writeup is due at 5pm on Thursday 1 May. Electronic turn-in is strongly preferred. Your project should include a complete (documented) code listing and a standard writeup including information about what you did in lab, who did what, how the code works, etc. You should also document any difficulties you encountered, any interesting features or experiences, etc. Also indicate credit for any code that you may have used but did not write. In addition to the code, your writeup should be between two and five pages. Only one writeup is due per team; however, the roles of each team member should be clearly indicated in the writeup.

In addition to these standard writeup features, the final project material should include a user's manual and a poster. The user's manual should be designed for someone who does not know or need to know how your project works inside; instead, it should contain enough information to enable others to successfully run your software. This manual should be at least one and no more than ten pages long, depending on the number of illustrations, the novelty of the application, etc. Again, only one user's manual is necessary per team, but include authorship information and division of labor.

The poster is the only part of the final project that need not be turned in electronically. It should be designed to accompany a running project demonstration in the absence of any team member. It may be either marketing or technical in nature, i.e., it can tell about your project and what it does or it can tell about how it works. In either case, it should communicate some of what you have learned during this semester. Although it will be used in the project demo on 28 April, its primary target is the class exhibition during Gates Week, when external visitors will be coming to campus.

You should also include a self-assessment checksheet for each member of the group. This will be provided during the last week of the semester.