Grading Policy
Projects will be graded on four criteria. The weight given to these criteria
may differ between projects.
- 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?
- 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?
- Javadoc — is javadoc created for
each class and
each method
that includes all required information?
Is the javadoc created without errors or warnings?
- 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 noticeably 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)
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
Compared to previous semester, there will NOT BE project regrades. Please be
careful on what submit.
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.