CS224 -- Spring 2012
Project #1: Assembly Language Programming
Design Review & Peer Grading Reports
Due Date: Tuesday March 13th, with submission being earlier, and pickup later. [Note: no one should miss a class on account of the submission or pickup—groups may send a representative who is not a member of the group if all members have class at the times stated below.]
Submission Time: Each group will submit the 3 reports detailed below (plus the Team Progress Report, don't forget that one!) between 13:05 and 13:25. No early submissions (before 13:05) will be accepted. Late submissions (after 13:25) will be penalized quite heavily, so make every effort to get your reports in on time, by the deadline!
Submission Place: The location of the submission is outside the door of EE-210. In the corridor, there will be 3 boxes, marked “Team Progress Reports”, “Originals” and “Photocopies”.
Submission Rule: Groups should prepare and submit the 3 Design Review and Peer Grading Reports (DRPGRs) which were assigned to them, according to the format and contents described below. The representative will submit the 3 DRPGRs to the box outside EE-210 marked “Originals”, then leave. Do not hang out near the door to the TA office, or talk or otherwise disturb others.
Photocopies: After your group has completed the 3 Design Review and Peer Grading Reports, and they are in final form, ready to turn in (this means with everything signed, in correct order, etc), you should make a high-quality photocopy of each one. All pages, including the cover page, should be photocopied—it should be 1-to-1 with the original. These 3 photocopies will also be turned in, to the box marked “Photocopies”. They are due at the same time and place as the original DRPGR reports.
Pickup Time: Each group (say Group X) will pick up the 3 Design Review and Peer Grading Reports, done by other groups who reviewed and graded Group X's Preliminary Design Report (PDR), from the TA in EE-210, after 16:30 on Tuesday March 13th. A representative of each group (or a friend) should come to EE-210, to pick up these DRPGRs. All groups should pickup the 3 Design Review and Peer Grading Reports that evaluated their PDR between 16:30 and 17:20 on Tuesday, then leave. Do not hang out near the door to the TA office, or talk or otherwise disturb others.
Format: Each of the reports to be submitted including the photocopies should be stapled in the upper left-hand corner. No folders or clear plastic containers!
Contents: Your group will do the design review and peer grading for 3 groups, and prepare 3 original DRPGR reports to turn in (and of course each DRPGR report will also be photocopied, and the photocopies are also turned in). Each Design Review and Peer Grading Report will consist of a cover page, and 2 other sections, arranged in this order: cover page, then design review, then peer grading. Details of each are given below:
· Cover page: The first page in your report is the cover/title page, with course number, semester name and year, name of the document, group #, name/ID/phone/email listed for each group member, along with the signature in ink of each person (signatures in pencil are invalid and unacceptable), and submission date. It should follow the format given in this link, but personalized for your group, of course. All members of the project team must sign the Honor Pledge, otherwise the report will not be accepted!
· Design Review: Your design review consists of the marked-up Preliminary Design Report that you evaluated and commented on (all pages, including the cover page), with your thorough review of each of the 6 utility routines directly written onto the pages of the PDR, at the appropriate places. For each utility (build, check, sort2list, insert, min_max, and find), include a review and critique of the verbal explanation of the group's solution/algorithm in English, a review and critique of the high-level model (HLL programming language or high-level pseudocode) of the group's solution/algorithm, and a review and critique of the intermediate-level pseudocode model of the group's solution/algorithm. For each of the 18 reviews (6 utility routines x 3 sections per routine), your review should contain opinions and suggestions about the following 4 aspects: 1) Completeness--did the group do all that was required, did they adhere to the specification completely? {Check the specification!} 2) Correctness/accuracy--did the group correctly understand the specification of the data structure and the utility routine, did they correctly model the algorithm and data structure needed for it in pseudocode, are there errors or omissions that need to be fixed? 3) Clarity: Understandability/readability/neatness--are the English explanations, figures, captions, and also the high-level and intermediate-level pseudocode (along with the headers, comments, and labels and spacing/layout) all of good quality, neat and clean, clear and easy to understand? 4) Overall quality--what is the overall quality of the English explanation, and the high-level and intermediate-level design work, and the documentation? {Your group's extensive comments about these things should be written onto the pages of the report you are reviewing, using space at the top and bottom and side margins, and extra pages if you need. Do not use the back of any pages, which might be forgotten in photocopying.}
· Peer Grading: The final page of your report is the completed Peer Grading spreadsheet, completely filled in. It should be exactly one page, with the cell entries typed (not handwritten). The Honor Pledge at the bottom must be signed by all group members. The grades given in the spreadsheet should correspond to and be in agreement with the comments written onto the PDR report that you reviewed. The template for the Peer Grading spreadsheet is given at this link.
Questions to ask, and things to look for, when doing your review:
In the trade-offs that need to be made (remember “Good design demands good compromises”), how well do you think the group chose in things like their algorithms, the overall structure of their code and pseudocode, their use of data structures, etc? Are there points particularly worthy of praise, good/excellent design approaches or clever implementations? Are there particularly bad choices that you think they made?
How efficient are the solutions in the PDR? Are there efficiencies that they missed, ways to make the solution/algorithms smaller/more compact (space), or ways to make the solution/algorithms faster (time)?
Is the documentation self-explanatory, or do you feel at points that you need to ask for clarification? (If so, the design documentation is not good enough). Code should be self-documenting, English expanations (including figures) should be clear and understandable.
----------------------------------------------------------------------------------------
Grading: The Design Review and Peer Grading Reports are worth 25% of the overall project grade. The 3 grades earned will be averaged together. Grading of each report will be based on the following criteria:
Adherence to the format given (18%)
Understandability and presentation of the design review (10%)
Completeness of the design review (42%)
Quality (accuracy and consistency) of the Peer Grading (30%)
Summary of steps to get ready for the March 13 submission
Lets
say that one of the 3 Preliminary Design Reports (PDR) that you were
given is from Group #99
First, you should do the design review
of Group 99's PDR, and write your comments in pencil or ink directly
onto the PDR pages (or put numbers in pencil or ink in the PDR,
refering to typed explanations on your own A4 pages, which you insert
into the PDR in the closest place possible to where the comments are
referring to, or to handwritten explanations which are on extra A4
pages, which you insert at the closest place.) (item 2)
Then
do the Peer Grading spreadsheet and sign it. (item 3)
Then
make your DRPGR cover page, and sign it. (item 1)
Then
assemble these 3 parts in the correct order: (item 1) then (item 2),
then (item 3)
You now have made one DRPGR, It is ready to
submit, except that it isn't stapled.
Then make a
high-quality photocopy of it.
Then staple the original
DRPGR report, and staple the high-quality photocopy of it.
Now
repeat the above steps for the other 2 PDRs you were given.
Now
make the Team Progress Report, and staple it.
On March
13th between 13:05 and 13:25, you or your representative must bring
the 7 reports to the submission place, and put the 3 DRPGRs into the
"Originals" box, put the 3 photocopies into the
"Photocopies" box, and the Team Progress Report into the
"Team Progress Reports" box.