next up previous contents
Next: Reusable Code Up: Paradigms for CAA Previous: Paradigms for CAA   Contents

Single-Purpose Testers: The ``Simple'' Approach

The ``greedy'' scheduling approach to Computer Assisted Grading is one that every programming-literate grader has probably dreamed of during the tedious hours of slogging through student programming submissions: ``Why don't I just write a script that does steps $X$, $Y$, and $Z$ for me and show me the results?'' Indeed, a well-written program spec for Computer Science classes can make the functional parts of grading almost completely automatic. This sort of grading aid, often written in a scripting language such as bash[14], perl[25], or python[20], can reduce the time requirement for grading the functional behavior of a well-specified programming assignment. Unfortunately, this has minimal reusability and can do nothing to assist with having to manually inspect student work for non-objective requirements like style and documentation4.1

This approach, possibly in conjunction with a text file containing comments pertaining to common student mistakes, can be used with some efficiency. However, in order for there to be a net-reduction in time spent grading, the development of such a script must be relatively straightforward. For ``meat-grinder'' programs like those that are commonly assigned in lower-division CS courses (programs that take a well-specified input format and produce a completely deterministic output of an equally well-specified format), the majority of this task can be automated with two nested loops and proper invocations of the diff utility under Unix. Programs that have any form of freedom in interface are often ungradeble using this approach, as are many upper-division programs where the complexity of the average assignment prevents any simple method for automating the testing. In general, this approach can pay off much better for lower division lecture courses with large enrollments. The development time is generally not feasible for courses with difficult-to-test assignments, flexible requirements, or low enrollment.


next up previous contents
Next: Reusable Code Up: Paradigms for CAA Previous: Paradigms for CAA   Contents
Titus Winters 2005-02-17