Okay. Take a deep breath. You've finished the last official lab. Everything else you do in lab is almost completely up to you. You'll be writing your own problems, scheduling your own tasks, managing your own team, and running your own show. Good luck!
The final project lasts from now to the end of the semester. You'll be presenting your final project to the rest of the class starting December 7. I know it seems like a long time from now, but effectively, you'll only have 4 weeks to complete a full programming project. Don't leave it all to the end! Remember: REM sleep solves bugs. Leave yourself plenty of time to solve lots of bugs!
| Nov 4 | Idea fair (oral/written) |
| Nov 9 | Project plan (written/oral) |
| Nov 16 | Interfaces (oral) |
| Nov 23 | Face-stuffing algorithms (gastronomic) |
| Nov 30 | Demo day (oral) |
| Dec 7 | Start of final presenations (oral) |
| Dec 12 | Final project writeup due (written) |
Presentation in lab, Friday, November 4. Writeup due at the start of lab.
Your first assignment is to come up with an idea for a final project. Your idea must be your own, and should be creative, fun, potentially useful (this isn't a requirement), and above all, achievable in four weeks.
Furthermore, it must satisfy the following three rules:
java.net package.
In the past, teams have built anything from networked video games to a multi-user chat program to a shared whiteboard. Be creative.
No matter what area you pick, you should be able to describe two extremes. At the low end, you should describe the bare minimum functionality necessary for the project to demonstrate its intention. You will be expected to get at least this far in the four weeks you have available for design and coding.
At the high end, you should come up with bells and whistles to make the program more functional, more usable, or just plain neato. A good project idea is one for which it is easy to reach the bare minimum, but has lots of room to grow in many different directions.
On Friday, November 4, you will have exactly five minutes to present your project idea to the rest of the class. Unless there are volunteers to go first, the presentation order will be randomly selected at the start of lab, so be sure to come to lab on time.
Your presentation may be accompanied by a poster of some kind with design sketches, or you may just write the title of your idea and a few scribbles on the board. In either case, your idea and the bare minimum target should be clear to everyone. Hopefully, you'll get everyone's thoughts bubbling about extensions and frills; to be safe, make sure you describe a few directions to extend the minimum yourself.
At the start of lab, you must turn in a brief description of your idea. This should be one paragraph describing your idea, one paragraph describing the minimum target, and a few bullets describing possible extensions. You can use a copy of this paper as your notes for your presentation.
Once everyone has presented your ideas in class, you'll have to sort yourselves into groups of 2 through 4 (we suggest 3) people. Everyone in the group must contribute to the final project, so make sure you're comfortable working with everyone in the group.
Then, get started brainstorming and working on...
Design document due by midnight, Friday, November 11. You will describe the contents of the document in conferences in lab on Wednesday November 9.
This document will completely lay out your idea, the bare minimum requirements, and a specific set of gravy goals you'd like to achieve. It should have a more comprehensive and detailed description than the homework of the person whose idea it was originally.
Don't be afraid to adapt or adjust the original idea.
In addition to the idea description, you should have a section that lays out your schedule for the next few weeks, and maps out where you expect to be each week from now until the project presentation. You should break the time down into milestones, both for design, and for the testing of parts of your system.
Although you will be turning in a version of this plan, you should consider it a live document. Things will go wrong. Somethings will take shorter than expected; many other things will take longer than expected. You may also find the design document a useful place to keep descriptions of your model, interfaces, and communicaton protocols. Keep your document up to date and make sure that whatever happens, you can still finish by December 7.
This part is just a brief description of the project, similar to what you talked about in class during the last lab. It should be obvious to someone who's never seen your project idea what your project is from the description.
These can be hand-drawn or mocked up using some other computer drawing program. Make sure you think about how the program starts, how the user will initially interact with your program, and what it should look like while the user is using your program. There should be one or two pictures for each interaction step.
Hint: find some unsuspecting victim a friend and show them the pictures without describing your project. Can they figure out what's going on? Would they understand what would happen if they clicked somewhere or typed something? It's very hard to do this without coaching them along, but if you can, and can listen to what they say, you can make a much better interface.
Your model description should indicate the data of the model and the types of listener interfaces that can be added to your model. Try acting out some of the buttons from your interface and make sure that your model contains all the information it needs. Remember the way to distinguish what goes in a model versus what goes in a view: if there are two ways to simultaneously represent the data of the model, the parts that are the same go in the model, and the parts that are different go in the view.
Are you sending objects across the network? If so, what objects? Are you just sending text strings? If so, what do they say? Make sure that everything that needs to be communicated from one computer to another is accommodated by your communication protocol.
You have from now until November 30 to get a demo running, and one more week (until December 7) to get your final project together. Plan out a timeline that specifies milestones (finished interface descriptions, each individual module that you can implement and test separately, your working base functionality, each drop of gravy) and the dates at which you intend to complete them.
Your schedule will fall behind. There's just no way around that. Therefore, you should compress it to make sure that you have some slop days before the demo and final presentation. Make sure that you've figured out beforehand what gravy you should cut first. Be realistic. The better you can design your plan now, the less disappointed you'll be when you can't get to pieces of it.
These aren't necessary for the project plan on Friday, but they're handy to have around and they can help you with your design. You'll also need them for next week's review, so it can't hurt to get started early.
This may seem like a lot, but remember that you've got three people in your group. Divide up the labor, and remember to communicate, communicate, communicate! Make sure everyone in the group knows what you're doing! Each section (other than the pictures) should be no more than one or two pages.
In lab, you're not required to have finished your design document. However, you should at least be able to coherently describe the answers to each of the sections. Make sure you have the drawings of your GUI ready so that we can talk about them.
Here is the order in which we'll talk to the groups:
| Order | Group | Project |
|---|---|---|
| 1 | Christie, Brad, Avery | Pictionary |
| 2 | Duc, Alex, Cody | Network audio |
| 3 | Keri, Ryan, Meena | Classy chat |
| 4 | Ginneh, Anne, Dan | Multiplayer Pong |
| 5 | Ben, Connor, George | Java Barrista |
| 6 | Matt, Hossam, Jeff | Cops 'n' Robbers |
Expect a half-hour for each group. If you'd like to change your order, confer with the other group(s) and let me know. Please also let me know if you have a preferred name for your group.
We have created a Subversion directory on Public for you, in
//fsvs01/Public/+Courses/Software Design/SVN/<teamname>
Oral description of your designed interfaces, in lab on Wednesday, November 16. There is no written portion of this week's work.
By November 16, you should have a good grasp of your design and at least a first stab (probably a second or third) at a set of interfaces you'll use for your program and the communication protocol you'll be using to get the instances of your program to talk to each other.
In lab on November 16, you'll describe your interfaces to us: what are the big concepts in your program design? How do your interfaces allow you to accomplish the bare minimum target without preventing you from easily adding on to complete your gravy? What are your abstractions?
You'll also be describing your communication protocol. Do you have a client-server style, or peer-to-peer style of communication? How do clients connect? How do they disconnect? What do they say to each other, using what Objects or strings, and in what order? What do you do when something goes wrong?
There is no required written portion of this week's work, but you may find it useful to print out your interfaces, or at the very least, construct a UML diagram of your planned classes.
Note that by this time, you should also have several small parts of your system written and tested. We'll probably ask you how you're doing compared with your design document. An updated document can make you look very good here.
There's a break for the Thanksgiving holiday during the week of November 21. Hopefully, you're far enough along by this point that you can relax and enjoy the holiday!
You should have a demo of whatever functionality exists in your project ready to go by Wednesday, November 30.
By this point, you hopefully have some functionality to your program. We'd like you to aim for at least the bare minimum target by this point. Remember, you've only got a week left of coding! For lab this week, you'll set up some machines to run your code, and your classmates will try it out. To this end, you'll need to create a very short manual describing what your code does and what the user can do to exercise the program.
It also means that you shouldn't be in the middle of completely re-writing your code when you hit demo day. Make sure that as much of your code is running as possible. Remember, your unconscious self knows all the fragile parts of your code and has subliminally been preventing you from breaking your own code. Your classmates have no such mental block, and they'll find all kinds of weirdness that you never knew was there. The more they can test, the better.
As a user of other people's code, please be gentle (at least initially). When (not if) you encounter bugs, please write them down so that the team can try to fix them. If you find something confusing, write that down as well, so that the team can make a better user experience.
Try to get to as many demos as you can in the first half of the lab time. Read through the bugs that other people have found first, and then try to exercise other parts of the demo.
In the remainder of the lab, you should read through the notes other people left, and go ask them for any clarifications you need. Then you can go about reproducing and fixing them. Try for a while and then get a good night's sleep. Remember, REM sleep solves bugs!
Final presentations start Wednesday December 7 in lab. Presentations will continue as needed on Thursday, December 8. You must be present for all presentations.
You will have 30 minutes to demo your project and present it to the class, followed by a 15 minute question and answer period.
You should describe what your project does, and give a high-level description of some of the abstractions and concepts in the code. You shouldn't talk about any of the nitty-gritties of the code unless you came up with a very cool algorithm for something.
Make sure that everyone in the group presents something. By this point in time, you should all understand how your code works. If something was a mystery, you should have been asking your teammate to explain it to you!
The presentations should be fun and engaging, and must include some kind of poster describing your project. The poster should be easy to understand even if a member of your team is not available to explain it.
| Order | Group |
|---|---|
| 1 (Wed) | Christie, Brad, Avery |
| 2 (Wed) | Keri, Ryan, Meena |
| 3 (Wed) | Duc, Alex, Cody |
| 4 (Wed) | Matt, Hossam, Jeff |
| 5 (Thu) | Ben, Connor, George |
| 6 (Thu) | Ginneh, Anne, Dan |
Some ideas for things to talk about:
All written project materials must be turned in during class on Monday, December 12.
Please turn in (electronically):
Only one final project document needs to be turned in per team.