CS35: Final Project

CS35: Programming and Problem Solving
Ray Ontko
Department of Computer Science
Earlham College

Final Project Specification due Wednesday, 1999/11/17
Final Project due Monday, 1999/12/06

Final Project

The goal of the Final Project assignment is to apply all that you have learned about programming and problem solving to solve a small but interesting problem. By tackling a larger problem over a longer period of time, you'll get a different perspective on what it is to write large programs that solve non-trivial (or at least interesting) problems. You'll also be working on a different problem from almost everyone else in the course. By doing so you'll need to rely more heavily on your own mastery of the material and your own resourcefulness in solving the problems you encounter.

You may choose from a number of recommended projects (each described briefly below), or you may create a project entirely of your own design. Use your imagination to come up with a program that you find useful or interesting. It should be something which you have confidence that you can work through before the end of the semester, and something that will keep you engaged for at least that long.

A good project can't be completed in a weekend, and you may find that you're more productive as a programmer if you set the program aside and come back to it with fresh eyes the following day. Waiting until the last minute precludes this tactic.

The final project comprises 30% of your grade (three letters of your final grade for the course).

Final Project Specification

You should prepare a proposed specification for your Final Project. The specification is due on Wednesday, November 17, 1999. The specification should describe what your program will do, what your program will not do, what input it takes (if any), and what output it produces. You should not describe every detail of your program. A specification should generally describe what your program is to do, but not the details of how it is to do it.

Feel free to bounce ideas off me before the specification due date. I may have suggestions on how to keep from getting in over your head, or features to consider including to make the program more interesting or useful. In any case, I'll try to give you quick feedback on your proposal at the time you submit it.

Be Specific

Avoid describing your program in general terms. Really try to nail things down. Instead of, "The program will take input from the user," consider, "The program will prompt the user for a valid move which is to be entered as a pair of numbers corresponding to the cells on the game board from which and to which the piece is moved." A specification should be specific.

Be Complete

Describe your program in enough detail that two different programmers using the specification would come up with functionally similar programs. Don't leave significant aspects of your program unspecified.

The more thinking you put into your specification, the less likely you'll be sidetracked by issues during coding.

Project Ideas

Your program can be "about" anything you like, but it should do something useful or interesting. It should incorporate many if not all of the programming constructs we have covered in the course. Here are some kinds of programs to consider:

Textual analysis. A program which reads a text and performs a number of textual analyses including word length, sentence length, paragraph length, letter frequencies, letter-pair frequencies, etc. It might produce a number of histograms to graphically depict the frequencies.
Encryption/decryption. A program which reads a text and encrypts/decrypts it using a "substitution cipher" (in which each letter of the alphabet is mapped to one and only one letter in an encrypted alphabet).
Decipher assistant. A program which reads a brief encrypted text and allows a user to interactively assign substitutions for letters.
Arithmetic tutor. A program which displays random arithmetic problems, checks the answer given, keeps score. Ideally, the program would allow multiple levels, and allow the user to resume "play" from a prior run of the program.
Fraction tutor. Like the arithmetic tutor, except that it provides problems involving fractions.
Typing tutor. A program which displays text to be typed by the user, and then checks to see if the text entered matches the text requested. Ideally, the program would include a mechanism to measure typing speed and may include some typing exercises.
Dice games. There are lots of games that involve dice (usually of 6 sides). Many games involve standard numerical dice (with 1 to 6 dots on the sides), but others involve dice with letters. Pick a game. Write a program that rolls the dice, enforces the rules, and keeps score. Your specification should include a complete description of the rules of the game.
Card games. There are lots of games that involve cards (usually of 52 cards in 13 ranks of 4 suits, but not always). Pick a game. Write a program that shuffles the cards, deals them to players, enforces the rules, and keeps score. Your specification should include a complete description of the rules of the game (or at least a URL pointing to rules your program will abide by).
Other games. Games like chess, go, and even checkers are beyond the scope of the course, but you may be able to write parts of these games. For example, you may be able to write a program that allows two people to play checkers, display the board between moves, and check to see if a move is valid. Be very careful when you write your specification to be clear about how much functionality your program will have.

Again, pick a project that you'll learn from and enjoy. Final projects are due Monday, December 6, 1999.