CS 212 Software Development

CS 212-01, CS 212-02 • Fall 2019

Project Verification

Each project grade is split into two components: tests (functionality) and code review (design). This guide details the process for verifying and grading the functionality of your projects. See the other project guides guides for other details.

Associated Assignments Project 1 Tests
Project 2 Tests
Project 3 Tests
Project 4 Tests (Web Crawler Only)


The project verification process is required to earn the functionality grade for each project and prior to every code review. Only request project verification if all of the following are true:

  1. Your project passes all of the project tests locally in Eclipse.

  2. Your latest project release passes all of the project tests remotely on the lab computers. Do not request verification until you have completed this step; repeated requests for non-passing code will result in a point deduction to the functionality grade.

  3. You do not have an open verification request issue on Github. If you have an open verification issue but want to verify a different release, edit the issue rather than close or delete it. You want to preserve the issue timestamp, which affects the order requests are processed.

  4. You have already passed the functionality for the previous projects. For example, you may not request verification for project 3 until completing the functionality for project 2 and may not request verification for project 2 until completing functionality for project 1.

If all of the above is true, follow the steps below to request project verification.

Verification Requests

To request project verification, create an issue on your Github project repository. See the Issues guide on Github for details.

Several issue templates have already been provided for you. Select the “Verification Request” template to get started.

  1. Change the issue title to “Verification Request: Project v#” where v# is the release you want verified. For example, “Verification Request: Project v1.0.1” for release v1.0.1 of Project 1.

  2. Replace FULL_NAME in the issue body with your full name. For example, “Sophie Engle”. This should happen automatically if you modified your issue templates.

  3. Replace GITHUB_USER in the issue body with your Github username. For example, “sjengle”. This should happen automatically if you modified your issue templates.

  4. Replace OLD_RELEASE in the issue body with the previous release you created. (This helps us make sure you are numbering the releases correctly.) For example, “v1.0.0” or “N/A” if this is your first release.

  5. Replace NEW_RELEASE in the issue body with the current release you want verified. For example, “v1.0.1”. This should be the same release number as in the issue title.

  6. If you need your tests/functionality grade updated, make sure to check the box next to “I need my project grade updated on Canvas” in the issue body. To do this, change the [ ] text to [x] instead or click the checkbox after saving the issue. Your grade will not be updated unless this is selected!

  7. Assign the issue to our TA Olivia (oliviakumar). This should happen automatically if you are using the correct issue template.

  8. Label the issue with the verify label. This should happen automatically if you are using the correct issue template.

  9. Label the issue with the appropriate project label. For example, add the “project1” label (all lowercase with no spaces) for Project 1 verification.

  10. Add the issue to the appropriate project milestone. The milestones should be either “project1”, “project2”, “project3”, and “project4” (all lowercase with no spaces). You will have to create the milestone if this is your first issue for the project.

  11. Verify you have followed all of the necessary steps in the “Verification” section. To check a box, change the text [ ] to [x] instead or click the checkbox after saving the issue. Do not create the issue unless you are able to check all of these boxes.

There is an example project verification issue in the project template repository:

If you make a mistake, please edit the issue. Do not delete the issue or close the issue and create a new one.

All of these steps have a reason; I track the number of issues related to verification and review for each project. I use these statistics to set the schedule each semester, and to track your individual progress.

Functionality Grading

Your functionality grade will be based on the date you created the issue that passed verification. If the issue date is before the checkpoint deadline, you will earn 100% on the project functionality. If the issue date is after the checkpoint deadline, your grade will be deducted 10% (up to a maximum of 30%) per week.

The functionality deadline schedule is below (assume all deadlines are at 11:59pm):

Project 100% 90% 80% 70% 0%
Project 1 ≤ 09/20 09/21 – 09/27 09/28 – 10/04 10/05 – 10/11 > 10/31
Project 2 ≤ 10/11 10/12 – 10/18 10/19 – 10/25 10/26 – 10/31 > 10/31
Project 3 ≤ 11/01 11/02 – 11/08 11/09 – 11/15 11/10 – 11/22 > 12/05
(Extended) ≤ 11/08 11/09 – 11/15 11/16 – 11/22 11/23 – 11/29 > 12/05
Project 4 ≤ 11/22 11/23 – 11/29 11/30 – 12/05 12/01 – 12/05  
(Extended) ≤ 11/29 11/30 – 12/05 > 12/05    

Keep in mind the project pass requirements for projects 1 and 2. All of your grades default to 0% if you do not pass the functionality of projects 1 and 2 by the project cutoff deadline on Thursday, October 31, 2019. You must also pass the functionality of project 3 by the last day of the semester (before finals) on Thursday, December 5, 2019.

The final project grade (for the entire category) will be capped at 115% at the end of the semester. For example, if you completed enough extra credit to earn a 125% in the project category by the end of the semester, your project grade will be capped to 115% instead.

Working Ahead

Worried about the deadline schedule and how slow code reviews progress?

You can work ahead on the functionality of the next project after passing verification, just not in the master branch used for the current project and code reviews. If you want to work ahead, create a separate branch for the next project. You can even create releases from that branch, allowing you to pass functionality for the next project while still undergoing code review for the current project.

However, you have to be comfortable with branching and merging in git if you choose this route. It is very easy to cause merge conflicts that can be difficult to resolve, and we can only provide so much assistance.

You cannot work two projects ahead than the project currently under code review.

 If your master branch includes functionality for the next project, you'll be asked to remove it and reschedule the code review. This could cost you a week, and undo your efforts to work ahead!

Extra Credit

Worried about missing functionality points? You can request extra credit opportunities in a public post on Piazza. These opportunities will be specific to the project, can be completed at any time, and are open to all students that missed points on that project.