Canvas will have group assignments. If for some reason you complete a group
assignment and not all assigned members participate, please add a hand-in
comment explaining the situation. You should make a reasonable attempt to
convene all group members in one sitting, but you should not hand in late
because one group member was unresponsive or missed an arranged meeting. If you
have concerns on this point please e-mail the course staff to explain the
situation. (This applies for all future group assignments as well.)
We suggest, but do not require, that you use Google tools for real-time
collaboration (in this case a shared spreadsheet for recording review results
as you go):
https://www.cmu.edu/computing/services/comm-collab/collaboration/google-drive/index.html
Do a peer review on the following code: OpenBSD qsort
version 1.10. (Note that this is an acrobat file so everyone will have
consistent line numbers to work with.)
You'll be using an industry-oriented peer review checklist for this review.
(This is NOT the same as Project 3/4, but it is the review checklist you'll be
using later in the course for your projects after Project 4.)
Spend a few minutes (no more than 5 minutes) getting general familiarity
with the file so you more or less understand what's going on. This is a
QuickSort implementation, and hopefully you've seen that algorithm before
somewhere, but that is not essential for the code review.
Assign the following roles within your group:
- Review leader & recorder (the first person listed in the group
assignment)
- Review leader is responsible for guiding the review, recording results, and
keeping all discussions to less than 60 seconds on any topic.
- Reviewers (everyone else). Reviewers split up items 1-17 in the checklist
roughly evenly. Ignore checklist item #18.
- For example, for 4 reviewers in addition to the leader: (1) items #1-4; (2)
items #5-9; (3) items #10-13; (4) items #14-17.
- It's OK to vary this assignment, but each reviewer should have primary
responsibility for about a quarter of the checklist.
- It's OK to swap roles partway through just to keep things interesting, but
keep a single role for each code block.
- Use this Peer Review checklist.
This is an industry-grade checklist for generic software and is DIFFERENT from
the project 3/4 checklist. However, you'll be using this checklist later in the
semester.
- Use this reporting form for ALL peer reviews in this course:
- Peer review issue log (Excel). Use this
exact form. Uploading this form to Google Drive and using Google Sheets to fill
it out in the review might be helpful for collaboration. Make a new copy of
this blank file on your google drive for every peer review you do during the
course.
- DO NOT CHANGE THE FONT SIZE! Do not shrink font to fit -- instead wrap
text to multiple lines in the cell.
- MAKE SURE all columns including "status" print on a single sheet
and are not split across sheets. If you adjust column width this might spill
columns onto another page. Fix that by narrowing some columns without reducing
font size.
- This sheet is optimized to be readible on Canvas for grading. It is OK if
some rows spill onto a later page, but make sure all columns in a row are on
the same page when printing and fonts are large as in this sheet (set at 16
point fonts)
- Do NOT put multiple spreadsheets on the same page when rendering to
acrobat. One spreadsheet per page maximum (sometimes one spreadsheet takes two
pages if rows spill over onto the next page).
- Consider using Google Sheets (or another service) to interactively manage
the issue log during the review. Download from Google Sheets in pdf format
might be useful to you.
Methodically go through the code starting at line 83 using the following
procedure:
- The review leader identifies a chunk of 1 to 10 lines (typically 4-5
lines) to focus on.
- Here are some hints as to good chunks to consider: (1) lines 83-88; (2)
lines 90-91; (3) lines 92-98; (4) line 99; (5) lines 100-102; (6) lines
103-108; ...
- Each reviewer looks ONLY at the assigned code chunk and looks at EACH
assigned item one at a time.
- A reviewer finding a problem states exactly this content in exactly this
order: Rule #, Line #, brief description; review leader writes them down in the
review log.
- When all reviewers have completed their checklist, review leader asks
"anything else?" Reviewers can spend a brief moment saying things not
in their assigned item list.
- Review leader returns to step #1, starting the next chunk
Stop when you've spent a half hour or recorded 20 defects --
whichever comes first. Hand in the review file. This is not a race; and it
is MUCH better to be thorough than fast. So the fewer chunks of code you look
at to find the first 20 defects, the better you are doing.
Supplemental Material:
RUBRIC:
- One document (Acrobat is probably the best) that is displayable by Canvas.
File name: P00_Group##.pdf. (For future peer reviews P00 will be replaced with
the project number being reviewed)
- Document shall be entirely in landscape format.
- Peer review logs shall take substantially the full width of the page with
only normal (1" or less) page margins on letter size output. Fonts on
materials not generated by the peer review spreadsheet shall be no smaller than
16 point.
- First page: all students in group, group number, project number being
reviewed, & TA who attended the TA meeting. If any student did not attend
the TA meeting, list that student name and say "Did Not Attend TA meeting
next to that name." This information shall be on a separate sheet on the
first page of the handin.
- Subsequent pages of the document are the peer review spreadsheets, one
spreadsheet per artifact from one author. (Thus, for group of 3 this is a 3
page document if one artifact or artifact set from each author is being
reviewed.)
- Each item in the peer review issue log describes which artifact it is for
(for example: Sequence Diagrams #SD-3, ... issue ...)
- Each page clearly identifies the project # being reviewed, the author, and
ALL the non-authors for that spreadsheet.
- Issues must be recorded but do NOT need to show resolved on the hand-in.
(You should resolve them later.)
- The checklist you used for the reviews.