CSCI 310 Spring 2008, Project Grading Rubric

Thanks to Gary for doing the brainwork behind the original version of this rubric

Please note that, at minimum, your project must compile without error.  If it does not, you will receive a 0 on the project.  It is ok to comment things out to get a non-working program to compile.

Your projects will be graded on the following characteristics:

  1. Correctness: (70%)
    • 10-9: Code shows correctness on all test cases it faces.
    • 8-7: Code shows correctness in all but a few cases and those cases are considered somewhat extreme.
    • 6-5: Code shows correctness on the major test cases.
    • 4-3: Major flaws in correctness, but runs.
  2. Test cases: (10%)
    • 10-9: Test cases exercise all aspects of the code needed to demonstrate correctness and are explained in an articulate and meaningful way. There are enough test cases, but not an overabundance testing the same characteristics over and over.
    • 8-7: A few minor/extreme cases may be missed, some aspects may be slightly over-covered, or the explanation may be slightly flawed.
    • 6-5: Major points are tested but the process is flawed either by over-testing in one area, ignorance of many areas, or an explanation that lacks clarity.
    • 4-3: A major test case is missed.
    • 2-1: The only test case is the initial example provided with the project.
  3. Documentation (10%)
    • 10-9: The documentation gives a clear description of how the code works. It is neither overly verbose nor overly terse -- it may utilize excellent variable and method names to self document where possible.
    • 8-7: Minor quibbles with the documentation -- a part that is unclear, or names that obscure meaning, but an excellent job overall.
    • 6-5: Major points are well-documented but there are some gaps as well that make it hard to follow everything.
    • 4-3: Documentation is incomplete, but what is there is helpful.
    • 2-1: Some documentation is included.
  4. Structure (10%)
    • 10-9: The code is well-structured. Functions are a reasonable length; objects are used well; inheritance is applied meaningfully when possible; the code is efficient and clear. I would be proud to show the code to others.
    • 8-7: Some flaws in the structuring but no major complaints. Perhaps a function is too long, some small reorganization could help, or a piece could be made somewhat more efficient, but overall this is an excellent example of code structure.
    • 6-5: There's at least one major ugly bit in the code.
    • 4-3: There’s really no apparent design there.

You will receive a score in each of the categories, these values will be put into a weighted average which will be your score on the project. For example, suppose your code receives a 10 on correctness, an 8 on test cases, an 8 on documentation and a 6 on structure. Your project score is (10 * .7) + (8 * .1) + (8 * .1) + (6 * .1) = 9.2. Each project is worth either 5% (project 1) or 10% (projects 2-7) of your final grade so the score will be weighted accordingly when it is used to calculate your overall grade.