Final Project

The final project consists of three milestones: The Proposal, the Status Report, and the Implementation.

Proposal

Milestones

Project Deadline 2023-07-24T23:59:00-04:00
Late Deadline not applicable
Grading Deadline 2023-07-26T23:59:00-04:00

Scoring

Students are asked a number of questions about their project in the proposal. For each question worth points on Gradescope (some, like the name of the project or a description of what it will do, are unscored), award:

  • 2 for a thorough answer that shows thoughtful consideration.
  • 1 for an answer that suffices, but lacks detail.
  • 0 otherwise.

Status Report

Milestones

Project Deadline 2023-07-29T23:59:00-04:00
Late Deadline not applicable
Grading Deadline 2023-07-31T23:59:00-04:00

Scoring

Students are asked a number of questions about their project’s ongoing development in the status report. For each question worth points on Gradescope (some, like whether they have encountered problems, are unscored), award:

  • 2 for a thorough answer that shows thoughtful consideration.
  • 1 for an answer that suffices, but lacks detail.
  • 0 otherwise.

Implementation

Milestones

Project Deadline 2023-08-04T23:59:00-04:00
Late Deadline not applicable
Grading Deadline 2023-08-09T23:59:00-04:00

Scoring

Ultimately, students will turn in their implementation. This is graded similarly to a regular project, except that students have defined the specification for this project by means of the “good” target they set for themselves in the final project (unless otherwise agreed in a conditional approval).

Per the specification for this project, students’ projects are expected to:

  • Use Django and JavaScript. The application must utilize Django (including at least one model) on the back-end and JavaScript on the front-end.
  • Be Mobile-Responsive. The application must be mobile-responsive.
  • Have a README. In a README file (whose extension can be .txt.md.adoc, or .pdf) in the project’s main directory, there should be a full write-up describing the project, what’s contained in each file, why certain design decisions were made, and any other additional information the staff should know about your project. This document should be sufficiently thorough for your teaching fellow to run your project without any need to contact you further with questions.
  • Have a video. Linked in the README somewhere should be a link to a 3-minute (maximum) video wherein the student demonstrates the main features of their project.
  • Provide installation instructions. If any Python packages are needed to be installed in order to run the web application, they are listed outright in a requirements.txt file.

Then, this implementation is graded as any other project would be, using the README and video as supplementary tools to assist your grading. This project is graded along the three of axes of Correctness, Design, and Style. Each should be treated as independently as possible (code that is very broken, but has some good ideas that didn’t come to fruition and is extremely well-styled should maybe earn a 2 for Correctness, a 3 for Design, and a 5 for Style, for example.)

Correctness

Award:

  • 5 if the requirements above are met and the student has fully implemented their “good” objective.
  • 4 if there are a few minor bugs, but nothing that significantly hampers usability.
  • 3 if there are several minor bugs, or one major bug, or at least one of the requirements appears to be missing entirely.
  • 2 if there are several major bugs, or at least two of the requirements appear to be missing entirely.
  • 1 for a very clearly low-effort (missing the implementation of three or more requirements) or very broken submission.
  • 0 for no submission at all.

Design

Design is primarily concerned with how elegant, efficient, readable, and clear the student’s code is. Some design questions to consider and leave feedback on include (but are not limited to):

  • Is the code unnecessarily complex?
  • Is code reused where possible?
  • Are there unnecessary loops, conditions, and/or variables?
  • Are there places where the student’s code could have been made more efficient?
  • Is the code logical in structure?
  • Is there repetition of code that could be more cleanly written with the addition of a function?

Award:

  • 5 for the best designs, with absolutely no room for improvement.
  • 4 for better than average designs, with maybe a few quirks.
  • 3 for good, solid designs, though there are a few suggestions for areas for improvement.
  • 2 for fair designs that feature significant room for improvement.
  • 1 for poor designs reflecting very little effort or consideration of design implications of coding decisions.
  • 0 for no submission at all.

Style

Style is concerned with the aesthetics of the code (whitespace, comments, etc.). Some style questions to consider and leave feedback on include (but are not limited to):

  • Is the student consistent about the use of single quotation marks vs. double quotation marks?
  • Is the use of spacing and indentation consistent?
  • Are there appropriate comments in the code?
  • Is the use of variable names clear, meaningful, and consistent?
  • Do files have appropriate names?
  • Are there places where an extra newline would help with readability? Are there places where there are too many unnecessary newlines?
  • Do lines run on for a long time where it would have been clearer to separate into multiple lines?

Award:

  • 5 for the best style, with virtually no room for improvement.
  • 4 for better than average style, with maybe a few quirks.
  • 3 for good, solid style, though there are a few suggestions for areas for improvement.
  • 2 for fair style that feature significant room for improvement.
  • 1 for poor style reflecting very little effort or consideration of aesthetics, commenting, etc.
  • 0 for no submission at all.