Evaluation Overview
This page contains an overview of how student submissions will be evaluated. Portions of this page are still in draft, but they are representative of the final policies; any changes will be announced in a class meeting.
“College-level writing” incorporates having good structure, correct spellings, appropriate vocabulary, clear evidence, and coherent arguments. Keep in mind that The Writing Center is available to all students to help you enhance and hone your writing skills.
Late work is not worth course credit.
Written Assignments
Written assignments are evaluated using triage grading with the following general rubric:
| Points | Criteria |
|---|---|
| 3 | Clearly addresses the prompt with college-level writing. |
| 2 | Does not clearly address the prompt or does not meet writing quality standards. |
| 1 | Does not clearly address the prompt and does not meet writing quality standards. |
| 0 | Late or no submission. |
Project Reports
A project report is a required element of project submissions. The report explicitly contextualizes your technical work within the theories explored in class. A well-structured report will directly and explicitly address the seven universal principles of design established by Norman in the class reading: Discoverability, Feedback, Conceptual Models, Affordances, Signifiers, Mappings, and Constraints. For each of these principles, the report should explain and justify the decisions made by designers. Justification can be empirical or theoretical, the former through usability testing and the latter by citing relevant literature.
Each design principle will be separately evaluated using triage grading according to the following table.
| Points | Criteria |
|---|---|
| 3 | Design is explained and justified empirically and/or theoretically, following principles of good formal writing. |
| 2 | Design is explained but inadequately justified, or the presentation fails to follow principles of good formal writing. |
| 1 | Design is inadequately explained or fallaciously justified. |
| 0 | Late or no submission. |
See the final project specification for additional details.
Software Systems
The evaluation of software systems takes place at two levels of granularity. First, the overall system configuration is evaluated in order to determine a grade maximum, using the following specification.
| Maximum Grade | Criteria |
|---|---|
| A | Project builds without warnings or errors, and the rationale for any suppressed warnings is clearly documented in the source code or README file. Build instructions are provided in a README file. |
| B | Project contains compiler warnings, suppressed warnings are undocumented or unjustified, or build instructions are not provided in a README file. |
| C | Project contains failing unit tests or inadequate unit tests of the model level. |
| D | Project cannot be built, crashes during routine execution, or contains no unit tests of the model level. |
With that global maximum in place, the project source code will be evaluated following criteria inspired by Robert C. Martin's Clean Code. Each criterion will be evaluated in general triage fashion, meaning that three points are awarded for essential correctness, one point for clear incorrectness, and two points for anything in between. Individual criteria reflect chapters in Clean Code; keep in mind that Chapter 17 provides a valuable checklist. You are also welcome to use the Project Checklist as provided in my Fall 2017 course description if you find it useful.
- Meaningful Names (Ch. 2)
- Functions (Ch. 3)
- Comments (Ch. 4)
- Formatting (Ch. 5)
- Error Handling (Ch. 7)
- Unit Tests (Ch. 9)
- Classes (Ch. 10)