Grading Policy

Projects will be graded on four criteria. The weight given to these criteria may differ between projects.

1. Design — does the design adhere to the project specification and follow correct OO and top-down design principles? Do methods perform just one task? Do the classes each model a single entity? Are the methods of each class appropriate for that class? Do the classes exhibit appropriate encapsulation and data hiding?
2. Implementation — does the code follow all course guidelines with respect to style and documentation? Does the code follow accepted OOP coding standards? Does the code use the most efficient algorithms and data structures? Does the executable meet the specified running time for the project? Are exceptions thrown where appropriate?
3. Javadoc — is javadoc created for each class and each method that includes all required information? Is the javadoc created without errors or warnings?
4. Correctness — does the project compile and run to completion without errors or warnings and produce the correct results? Each facet of your project will be tested independently to the extent possible.

Any project that does not create an executable for any reason will lose all points allocated to the "correctness" criterion. Use the tools available to you (i.e. ant run and ant doc) to be sure that you have submitted all necessary pieces to create a runnable program.

Each project grade will broken out in a grading sheet that is specific for that project.

Project Grade Changes

Project grade changes are rare.

If you believe that a grading error has been made on your project, you should approach one of the graduate TAs with your concern. You must be prepared to show the TA evidence of the specific mistake. You must make your request within 7 days of receipt of your grade.

Please check your program on GL using the test cases used for grading before you ask for a grade change. Test cases used for grading will be released after the projects have been graded.

Examples of valid grade change requests:

• Addition error in the computation of your score.
• The grade sheet says a file was not submitted, but it actually was.
• The grader forgot to run a test case and deducted points.

Examples of invalid grade change requests:

• You think 10 points is too much to take off for a particular mistake. (The answer will be: "We took off 10 points from every student who made this mistake. We won't regrade all the projects.")
• Your program runs on your own PC/Mac, you think something is wrong with Java on GL. (You have to test your program with Java on GL.)
• Your program works when you run it on your own test cases, but not on the test cases used for grading. (Thorough testing is the programmer's responsibility. You should have found those bugs yourself with robust test cases.)

Your instructor is the final arbiter for your project grade. If you have spoken with a graduate TA and believe that you were treated unfairly (this would be very rare), see your instructor.

Project Regrades

In some unusual circumstances you may receive a low project score because of a single, simple error that results in many incorrect outputs, a program that runs too long or results in a compiler or build error. The definition of "simple error" is determined by your instructor. In such cases, your instructor may (at his/her discretion) allow you to fix the simple mistake and have your project regraded.

Requests for a project regrade under these circumstances must also be made within 7 days of receipt of your project grade.

Final Words

If you cannot complete a project, do submit whatever you have completed for partial credit. Projects that do not compile or do not execute will be graded on effort. In these cases, the grader will make a judgment call and estimate the amount of work it would take to complete the project.