CMPS115 Quiz Grading, Spring 2003

General notes on grading: All questions were weighted evenly, 20%
each.  However, if someone really nailed answer, I gave extra credit
up to an extra 5%.


1. This one should've been easy: in the context of the class,
schedule, budget, then features is really the only right choice.

Few people got full credit on this question.  First, they didn't
understand that "budget" means generally the amount of resources
expended and, in this context, the amount of time/effort the project
members invest in this project (versus other classes and/or sleeping).

Second, didn't seem to fully understand how to prioritize.  If in
doubt, ask yourselves: If the project is not going to hit its plan,
what can we change?  In the context of a class, the HARDEST thing to
change is the schedule (it's being imposed on you), so hitting your
deadlines becomes your first priority.  The next hardest thing to
change is the budget: while you can, on the margin, put extra time
into the class, you probably can't double or triple that amount of
time.  Thus, hitting your budget becomes the second priority.
Finally, we indicated several times during the course that you could
re-negotiate the scope of your project, i.e., features, being easiest
to change, is your lowest priority.



2. I pretty much gave credit for any distinct qualities copied out of
the readings as long as some decent reason was given.  Let me just
point out that **timeliness** would've been a great answer for an
"important" quality (following the scheduling discussion above) -- I
gave extra credit for that one.


3. An adequate solution (better ones were possible):

                                     +---------+
                                     | Request |
  +--------------------+             +---------+
  |RequestHandlerThread|                  |
  +--------------------+                  ^
                                         /_\
  +-----------+                           |
  | AuthState |                 +---------+----------+
  +-----------+                 |         |          |
                             +-----+   +-----+   +--------+
                             | Get |   | Put |   | Delete |
                             +-----+   +-----+   +--------+
                                |
                                ^
                               /_\
                                |
                            +------+
                            | Post |
                            +------+


    RequestHandlerThread     AuthState      Request 
             |                  |              :
             |--- checkAuth --->|              :
             |                  |              :
             |<-----------------|              :
             |                  |              :
             |----- create ------------------->|
             |                  |              |
             |<--------------------------------|
             |                  |              |
             |                  |              |
             :                  :              :
             :                  :              :


4. Most people got around 1/2 credit for this question because they
failed to list enough test cases.  Good unit testing is a bit tedious
because there often are quite a few cases.  But, with practice, you
can generate them very quickly.  I was able to come up with over 50
independent, black-box text cases in just a few minutes.

I gave people 5 "baseline" points for doing a reasonable job of being
systematic about generating cases, plus 1 point for each independent
test case.  I gave two points for more obvious cases (such as a null
string as an argument, plus REALLY long strings as input).


5. I gave 15% for listing the steps, plus 5% for pretty much any
discussion of strengths and weaknesses.  Most people copied the steps
out of the Ackerman et al paper, which was fine (re-read that paper if
you want to see the steps).  However, I also looked for two specific
points that I mentioned in class: first, the importance of picking the
right module to review, and second the importance of consistent
line-numbers on the print outs.