A Handbook for Teaching and Learning in Higher Education Enhancing academic and Practice

Computing science
❘
295
moderates prior to feedback being e-mailed to the students. The use of slider bars,
buttons and other graphical devices in the user interfaces speeds up the process
as much as possible. Finally, BOSS contains a tool called ‘Sherlock’ which assists
the module leader in detecting assignment submissions that have degrees of
similarity, and are possible instances of plagiarism.
The response, both of staff and students, has been generally very favourable. The
overall time taken to manage an assessment has been substantially reduced, and
the consistency of marking is invariably high. The number of successful appeals
against errors in marking has been reduced to almost zero. Regular use of a
plagiarism detection tool has reduced the identifiable number of disciplinary
offences to very small numbers. In situations where no tests are to be performed,
and where BOSS is simply a device to facilitate assignment submission, it has
proved to be a highly effective administrative tool.
The successful use of such a tool should not be a surprise to a computer scientist.
What is of particular interest is the process of developing the tool, and the issues,
both technical and pedagogic, encountered during its development and
deployment.
BOSS was developed ‘in-house’ since no comparable tool was available to
purchase (and even now there is none that would satisfy our current needs),
and general issues about developing large-scale software are therefore relevant.
For example, initial coding, maintenance and development of the software
require suitably skilled programmers who are seldom willing to work for the
remuneration which UK universities are able to afford. The software is ‘missioncritical’,
and staff and students must have full confidence in it. Security is
paramount (and must be demonstrably so), and thorough testing is crucial.
Automatic tests on computer programs are notoriously difficult to write, and
even small programs yield unexpected surprises. Early versions of BOSS allowed
such tests to be specified so that text output of programs was compared to the
expected output. Variations in punctuation, white space, number presentation,
and even spelling, could cause tests unexpectedly to fail for individual students.
Tight specification of a program’s behaviour gives rise to student criticism that
the software is too ‘picky’, whereas the alternative reduces the effectiveness of the
testing harness. The specification of tests in the context of graphical output or
input is difficult (although the use of Java objects can be helpful).
If an assignment carries a significant proportion of a module’s marks, it is
undesirable for all of the marks to be awarded for automatic tests. Furthermore,
there must be a manual check of any automatically awarded marks to ensure that
no unforeseen system problem has accidentally penalised any students (and this
is now a requirement of the university).
Perhaps the major lesson we have learnt is that computer systems are invariably
much less reliable than we would desire. When 200 students are attempting to