Programming Project 1: Grading Criteria

Below please find the grading scheme we used for phase I of the programming project.

Regrades. If you believe that the grading scheme was misapplied, then you may submit a hardcopy, written regrade request at room 4115 Upson prior to April 12. This request should include:

For such requests, we will review the entire project and the way that it was graded. Your grade may increase or decrease as a result of the increased scrutiny.

Specious regrade requests are strongly discouraged and will be dealt with harshly. If your regrade request does not have a credible basis, then we will assume that you understand even less about the project than your original grade indicates. And your grade will be reduced.

Course staff are prohibited from discussing grading or grades.

Possible Project Grades and What They Mean

E (Excellent)
Implemented request-reply using RSA, DES variant, and signatures, and provided logging; also implemented an acceptable scheme for defeating replay attacks. An ideal scheme for defeating replay attacks minimised the "window of vulnerability" of the system to an attacker, in particular, not retaining information in the server's memory for more than the duration of a single transaction. Schemes that relied on clock synchronisation between the ATM and bank, for instance, comparing ATM clock values and bank clock values, were not acceptable, and did not receive an E.

VG (Very Good)
Implemented request-reply using RSA, DES variant, and signatures, and provided logging.

GF (Good Faith Attempt)
A partial solution was submitted. Conceivably, it could be completed to reach VG or E.

U (Unsatisfactory)
The solution did not show understanding of the problem at hand or its solution.

Groups that did not submit documentation were additionally penalized.

Grading worksheets returned with your project record what the grader thought your code did. You were not necessarily penalised for all the problems noted on the worksheet.