Path: utzoo!attcan!uunet!husc6!purdue!narten
From: narten@cs.purdue.EDU (Thomas Narten)
Newsgroups: comp.edu
Subject: Re: looking for cheating detectors
Message-ID: <4513@medusa.cs.purdue.edu>
Date: 23 Jul 88 00:46:54 GMT
Sender: news@cs.purdue.EDU
Organization: Department of Computer Science, Purdue University
Lines: 36

In article  <405@comdesign.UUCP> pst@comdesign.uucp (Paul Traina) writes:
>A copy-discovery program is incredibly complex and quite easy to fool.
>If you were at the latest USENIX, you saw the presentation on SPIFF and
>how difficult that sort of context-diff program was to develop.
>
>*Commentary*	Let them cheat.  If they're smart & learn, it's no big
>		deal.  If they're stupid, they'll blow their final and
>		they won't do well in courses that build upon the
>		material presented in your course.
>

Cheating is a matter of ethics; it is a "big deal".

Second, a relatively simple analysis program can snag a lot "similar"
programs, where similar means that if one looks at the programs side
by side, there is no doubt that collaboration has taken place.  I
know, because I wrote one once.  I was shocked at:

1) the number of programs that had been collaborated on (20% in a
course of 750)

2) the simplicity of the algorithm that netted similar programs.
Counters of specific keywords, control structures, subroutines and
variable names were the only thing checked.  The program did little
more than lexical analysis.

3) the difficulty in convincing students that what they were doing was
wrong.  Roommates swore up and down that they had not shared code, yet
it was obvious to the instructors involved that nuances in the
finished assignments could not have occurred by chance.

Moral of the story: it's relatively easy to catch cheaters; the hard
part is figuring out what to do with them once they're in your office.
-- 
Thomas Narten
narten@cs.purdue.edu or {ucbvax,decvax,ihnp4}!purdue!narten