As mentioned in a previous post, I employed standards-based grading (SBG) in my parallel programming course this semester. I will try to highlight in a few posts how I felt it went and how I will try to make use of it in the future. This post discusses some general student feedback on the use of SBG and discusses how I designed the class.

Twenty of the twenty-eight students in the course responded to a set of extra course evaluation questions that I provided, and of those, about 10 were positive to very positive. The most common positive comments were along the lines of:

- The course assessment style reduced the stress of tests and allowed more focus on the material than cramming for tests
- Reassessments allowed improving my understanding of the material over time
- I think I will have a deeper understanding of the material after the course ends

The gist of the comments that were less positive were:

- The grading scale and processes were initially confusing
- Small errors on assessments leading to an “R” was frustrating
- The approach seemed to be more work for the professor than typical courses (in time spent crafting assessments and grading)

I started off the course planning to cover and assess a total of 23 “knowledge” standards and 3 “programming” standards (one programming standard for each different parallel programming toolkit that was covered in the course). I ended up only assessing the students on 13 knowledge standards and the 3 programming standards. We covered some material related to additional standards during the last two or so weeks of class, but I didn’t end up assessing the students on that material.

I used the first half of most Tuesdays in the course as an assessment period, where students would take one or two assessments (chosen by me) and then could take one reassessment (chosen by the student). Students could reassess on a standard as many times as they wanted, under the constraint they could do at most one reassessment a week. Students had to submit an online form by noon on Mondays indicating which standard they wanted to be reassessed on. The midterm and final exam periods were reassessment periods where students could opt to do as many reassessments as they preferred on those days.

For the programming standards, I assigned 8 problems over the course of the semester that would take between 1 and 2 weeks each to complete. Students were required to submit 6, two for each the thre parallel programming APIs we learned about during the semester. The initial plan was that students, if they needed to be reassessed on a programming problem, could complete another of the 8 problems using the same toolkit as they had used in solving the original problem they were requesting reassessment on. Due to slowness on my part in getting some of the labs back (they took a while longer to score and provide useful feedback than I expected), I ended up allowing “correcting and resubmitting a given problem” to be used to raise an R grade to an M, or submission of a solution to another problem if the original score was an R or M and an the opportunity to earn up to an E was desired .

All grading on assessments and programming problems was done on an EMRN scale. Homeworks (called guided practice) were graded on an effort basis and consisted of 4-5 questions that related to a pre-lecture reading. One point per question was awarded if the student made a good faith effort on a question.

The overall semester grade was based primarily on how many standards a student achieved an M or E on. The homework grade influenced whether a + or – was awarded based on the percentage of homework grades earned. Students were given five tokens at the start of the semester. These could be submitted (1 token per programming problem) to have a 48-hour no-questions-asked deadline submission on the programming problems. Any remaining tokens at the end of the course could be submitted and credited towards guided practice points at a rate of 1.5 points per token.

Here is a list of the knowledge and programming standards that ended up being covered, and here is the overall semester grade scale. *05/31/2017 edit:* Here is the rubric I used to grade programming problems.

I hope to write two more posts on this in the future:

- Some statistics on the course (number of reassessments taken, etc).
- Things I would change or like to try in a future SBG offering of the course and in using SBG in my other classes.