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. Implemenation — does the code follow all course guidelines with respect to style and documenation? 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.
This means that turning in a project that "works" but is poorly organized or poorly documented or is noticably inefficient will not receive full credit.

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 and the CVS utilities) 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

All projects are graded by your TA. Visit your TA during regular office hours (or make an appointment) to request a project grade change when you think the TA has made a mistake. Come prepared to show the TA evidence of the specific mistake. Project grades will not be changed just because you think the TA has graded your project harshly.

Don't waste your time or your TA's time by asking for a grade change just because you're not happy with your grade.

Remember that if you have a question regarding your project grade, you have exactly one week from the receipt of your grade to contact your TA.

Your instructor is the final arbiter for your project grade. If you have spoken with your TA and still feel you were treated ufairly, see your instructor.

Project Regrades

In some unusual circumstances you may recieve 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 discretion) allow you to fix the simple mistake and have your project regraded.

Remember that if you have a question regarding a project regrade, you have exactly one week from the receipt of your grade to contact your instructor.

Students are encouraged to use the CVS utilities provided for verifying that your submission was successful. With these utilities and "cvs -q update" students have several tools to verify that your project is working correctly after it has been submitted.

In particular this means that statements such as, "It worked in my directory" or "It worked on my PC" will carry little weight.

Compilation/build regrades

As noted elsewhere, CVS is used for project submittal and ant (with its related build.xml file) is used for project compilation and execution. A regrade will be permitted if your project fails to compile due to a problem related to CVS, ant or build.xml.

Because using these tools correctly is a course objective, because time is spent in class describing how to use these tools, because TAs are available for assistance and because utilities and hints are provided to prevent these types of errors, the point deduction for these regrades uses an escalating scale. The more times you require a regrade for compilation/build errors, either in the same project or subsequent projects, the more points are deducted.

A project may be regraded multiple times for compilation/build errors.

Execution Regrades

If your project compiles/builds correctly but fails to run successfully (e.g. a Java class cannot be found) or runs too long or produces the wrong results because of a trivial coding error (as determined by your instructor, typically less than 10 lines of code) you may be allowed to correct the error and have your project regraded. Regrades are NOT granted so that you can rewrite or add a method, add a new class, or just get more time to finish your project.

A 10% deduction is assessed when your project is regraded due to problems with execution.
A project may be regraded only once for execution problems.

Running on Linux

Note that your project will be graded by being compiled and executed on the LINUX GL system (not IRIX). Be sure that you compile and test your project on a GL Linux machine. Compiling it and testing it under IRIX, Windows or any other operating system does NOT guarantee it will perform properly under LINUX.

Hints for enhancing your grade

Do submit partial work for partial credit. A zero grade is much worse than a low non-zero grade.
Do check your submittal by using our cvs utilites, ant run, and ant doc.
DO NOT wait until the last day to move your code to GL