Evaluation of Project #______

Project team ________________________________________________________________

For more information about any of these grading criteria, refer to the project grading policies page.

Initial Specification:   (30%)
Correctness / completeness: All necessary features considered. ______________ (up to -10%)
Correctness / completeness: Proper handling of unusual / malformed inputs. ______________ (up to -5%)
Correctness / completeness: Reasonable implementation plan, where the program comes together incrementally. ______________ (up to -10%)
Efficiency: Believable big-O analysis of time and space usage. ______________ (up to -5%)
Efficiency: Consideration of actual volumes of input, whether program can handle it. ______________ (up to -5%)
Elegance: Clean, modular separation of code. ______________ (up to -10%)
Elegance: Appropriate use of object-orientation or other PL features. ______________ (up to -10%)
Elegance / Extensibility: Consideration of features beyond the project spec. ______________ (up to -5%)
Elegance / Extensibility: Ease of upgrading data structures and algorithms. ______________ (up to -5%)
Clarity: Sufficient information for another Comp314 student to reimplement the project without any unanswered questions. ______________ (up to -10%)
Clarity: General quality of writing? Concise explanations. Useful examples. Helpful diagrams. ______________ (up to -10%)
Spec Subtotal ______________ (30%)
Prototype:   (30%)
Correctness / Completeness: Do unit tests cover major functionality? ______________ (up to -10%)
Correctness / Completeness: Does the prototype run? Did the implementation follow the plan from the spec? ______________ (up to -10%)
Elegance: Is it straightforward to add missing features? Is it clear what is finished and what remains to do? ______________ (up to -10%)
Clarity: Are the interfaces clean and well-documented (e.g., with good javadoc comments)? ______________ (up to -5%)
Specification: Has the spec been updated to reflect changes made during the implementation? ______________ (up to -5%)
Specification: Does the README indicate how to operate the program and what features have and have not been implemented? ______________ (up to -5%)
Prototype Subtotal ______________ (30%)
Final:   (30%)
Correctness / Completeness: Do all unit tests pass? ______________ (up to -10%)
Correctness / Completeness: Does the program work correctly with `normal' input? ______________ (up to -10%)
Correctness / Completeness: Does the program work correctly with `abnormal' input? ______________ (up to -5%)
Efficiency: Does the code consume reasonable time and space to perform its job on normal inputs? ______________ (up to -5%)
Efficiency: Does the program scale to larger volumes of inputs? ______________ (up to -5%)
Elegance: Does the final codebase reflect careful design or is there evidence of patching things together at the last minute? ______________ (up to -5%)
Elegance / Extensibility: Does the final codebase reflect general-purpose design? Can modules be separated out from the code and potentially be used elsewhere? ______________ (up to -10%)
Clarity: Are class and variable names well chosen? Is the javadoc sufficient that another programmer could use one of the code modules without looking at its source code? ______________ (up to -10%)
Specification: Has the spec been updated to reflect changes made during the implementation? ______________ (up to -5%)
Specification: Does the README indicate how to operate the program and what features have and have not been implemented? ______________ (up to -5%)
Final Subtotal ______________ (40%)
Late? ______________
Cool points (Features that are above and beyond the given requirements) ______________ (up to 5 extra)
 
Total ______________ (100%)

This is intended as a guideline only. Graders generally make project-specific tests and assign their own point breakdowns to these tests, but generally try to fit their comments into these guidelines.

Comments:

 

 

 

 

 

Last modified: January 12, 2006 8:34