Final Project

• Home
• Mechanics
  
  • Initial Handout
  • Syllabus
  • Learning Objectives
  • People
• Course Text
• Assignments
• Links
• Wiki

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. There is a small possibility that non-networked applets will be allowed as projects. You are welcome -- even encouraged -- to come up with your own ideas.

No matter what project you choose, your project must be approved by 13 November. 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.

Lab Structure

The labs during the first three weeks of the project -- November 10, 17, and December 1 -- 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 November 10/12 (specifically, by 24hrs before your project conference), 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

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 10 November (or by appointment 12 November), you will make a formal project presentation. We will schedule presentation conferences in class on Thursday 6 November. 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 24hrs before your 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 17 November.
   4. You may choose to further specify specify the second checkpoint to be demonstrated on 1 December. 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, November 6.

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 8 December your project will be available for demos. In addition, in class on Tuesday 9 December, 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 8th.

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 11 December. 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.

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.