Programming Project 3: 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 May 15. 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)
A solution with a good user-interface based mechanism for modifying policies, or a comprehensive and flexible policy language, or both; and a good list of policies, some implementation of groups of subjects, and an efficient, scalable implementation.

VG (Very Good)
A solution with an implementation of a user-interface based modification mechanism or a policy language, not as sophisticated as an E solution, or having no groups for subjects, poor scaling, or only one account per customer.

G (Good)
A solution with a fixed access control policy, unintuitive and unwieldy policy language, or a very restrictive modification scheme.

GF (Good Faith Attempt)
A submission with an incomplete or infeasible design or partial implementation.

U (Unsatisfactory)
A submission showing no significant understanding of the problem, or a highly incomplete one.

Policy discussions are not mentioned in the above grades, but were taken into account in modifying grades; poor or incomplete discussions resulted in a lower grade.

Extra credit was given for implementing both a user-interface based modification scheme and a policy language well, and for particularly clear and well-illustrated documentation.

We considered "scaling" to have two dimensions: administrative convenience and access time. Incorporating groups for subjects makes the scheme easier to implement, because the majority of subjects can use just the default behaviour for their groups. Access time requires an efficient storage scheme for the access control data; a matrix is fast, but prohibitively expensive in terms of space. Using some variant of linked lists is acceptable providing that an argument is made that the lengths of the lists are likely to be kept small, groups will obviously help here. A hash table implementation would of course be the most efficient!