CS 150 - Final Project

Your final project will be a program of your own design, which will demonstrate your mastery of the concepts learned in this course. This final project will take the place of a final exam, and should be an equivalent amount of effort to 3 weekly labs. You make work in pairs on the project - if you do, your final grade for the project will be weighted by your partner's feedback on your efforts. You will demonstrate your projects for me and the rest of the class during our finals period on Friday, December 19th from 2-4pm, and all code and write-ups will be do then.

Your program will need to use all of the following programming techniques:

Loops (either for or while)
Functions
Strings or Lists
Exception Handling

Additionally, you will need to use at least 2 of the following 4 techniques:

Recursion
Classes and Inheritance
Searching and Sorting
Multiprocessing and Synchronization

In this project, you will be responsible not only for creating a program, but also for documenting your code, both for users of your program, and future developers. You will submit not only all python files necessary to run your program, but also user.txt, a text file describing how a user should interact with your program, and maintain.txt, a text file where you describe the basic design of your program, how it uses each of the programming techniques you used, and "lessons learned" where you describe what you did that worked, and what you did that didn't work or you wouldn't do next time. You should also copiously comment your program files.

Project Rubric

The following rubric describes what I expect on your project. In general, "Poor" corresponds to a F/D grade, "Okay" to a "C/B", and "Excellent" to an "A".

	Poor	Okay	Excellent
User Documentation	Documentation is sparse or poorly written. It is unclear what the user should do for the majority of the program	Documentation is mostly clear. User actions are specified for most of the program.	All documentation is clear or well written. All actions that the user is able to take are clearly documented, for all situations in the program
Maintance Documentation	Program organization is not explained. Use of programming techniques is not explained. Lessons learned does not reflect understanding of basic programming concepts.	Program organization is documented, but not explained or does not make sense. Use programming techniques are explained, but techniques may feel tacked on or be used innapropriately. Lessons learned does not reflect understanding of programming concepts, or learning from project.	Program organization and the reasoning behind it is well explained. Use of programming techniques is explained, and how they are used reflects understanding of the techniques. Lessons learned demonstrates understanding of basic programming techniques, and reflection on experience programming for the project.
Use of Techniques	Not all programming techniques are used. Techniques are used in a superficial way, and there are only a couple examples of each technique	All programming techniques are used, but most have only a couple of examples.	All programming techniques are used throughout the program. Use of techniques demonstrates understanding of the concepts taught in class.
Overall Program Design	Program is not well organized. Code is not broken up into functions. There is a lot of "cut-and-paste" coding.	Code is mostly broken up into functions and classes, but there are parts of code that duplicate or unclear organization.	All code is well organized into modules, functions and classes. There is no duplicate code. Functions and variables are well named.
User Experience	Program is confusing to use. There is little functionality. Program does not work as described in the documentation.	Program works as described in the documentation. Program mostly works in a way the user would expect from using similar programs, but may be confusing in parts.	Program use seems intuitive. Program is fun to use and aesthetically pleasing.
Exception Handling	Program frequently crashes, even when being used as described in the documentation	Program does not crash when used as described, but will crash if unexpected input is entered.	Program never crashes, and provides helpful error messages when incorrect input is entered.
Comments	Majority of the code is uncommented	Most code is commented, but some tricky coding pieces are left uncommented.	All functions and classes are commented, along with any confusing pieces of code.

Handin

If you followed the Honor Code in this assignment, insert a paragraph attesting to the fact within one of your .py files.

I affirm that I have adhered to the Honor Code in this assignment.

You now just need to electronically handin all your files. As a reminder

 
     % cd             # changes to your home directory
     % cd cs150       # goes to your cs150 folder
     % handin         # starts the handin program
                      # class is 150
                      # assignment is 12
                      # file/directory is lab12
     % lshand         # should show that you've handed in something

You can also specify the options to handin from the command line

 
     % cd ~/cs150     # goes to your cs150 folder
     % handin -c 150 -a 12 lab12

File Checklist

You should have submitted the following files:

  all .py files for your project
  maintain.txt
  user.txt
  partner.txt (if you are working with a partner)

If you are working with a partner, you will both turn in partner.txt, with the name of your partner and a rating of how working with them went.