Guidelines for Research Student Review Talks and Review Reports
These guidelines are provided on a best-efforts basis.
The aim in both cases is to indicate what you've been doing since you
started your degree, or maybe since your previous review.
Headlines: make sure you describe past work, the gap, and your
evaluation plans. Further details are below.
What you should have been doing is a mixture of reading, design-type
work (which might include what a software engineer would call requirements
analysis), implementation, testing, evaluation (by you, of what you have
done), and writing-up. How much of each depends on how long you've been going.
When you give a talk, or write a report, for review purposes, some of the
things that you need to convince the review panel of are:
- that you have read plenty of relevant papers and books and now
understand the field. You should refer to papers in
which the concepts that you are describing are first described:
"QR-networks (Smith & Wang, 1994) solve the problem of ...". This
allows the audience to ask, during question time, "have you seen
the work of Chan & Jones (1996) on QR+ networks" - this may put you
onto some valuable new material. In a talk, it is not necessary to
have a detailed reference list to specify all these papers in detail.
In a report, you should have a bibliography.
- that you have found something which has not previously been "done"
- this is sometimes referred to as "the gap" - your talk/report should
make clear what the gap is;
The gap may be something that has never been done at all, or a new
(better!) way of doing something that has already been done. In the
first case evaluation may consist of showing how useful your new
thing is. In the second case, evaluation may consist of showing how
much better your new way is. In this case, especially, you may find
yourself using statistical methods. Make sure you know and show in advance
that your planned statistical evaluation is mathematically valid.
- that you have developed a fairly detailed plan for filling this gap;
- that you have developed a plan for testing your system when it is
complete. It is important to work this out in advance: if you finish
your implementation only to find that your "advance" cannot be
evaluated, you will be in a mess.
This much would be about right for a first review. Subsequently you would
proceed to implement your plan:
- design, coding, verification/testing in the software engineering sense;
- difficulties overcome.
- evaluation of your system by you, to show how great it is, and compare
it to other relevant systems or approaches;
- writing up (allow at least six months for this, and bear in mind that
in some cases during writing up, you suddenly discover a much better
way of doing things. This is often because the discipline involved in
describing your work for others makes something clear to you that you
had never previously seen or fully understood. You might then need
to modify your system and re-evaluate it. So start writing up early.
Back to Review Guidelines
Maintained by Bill Wilson
School of Computer Science and Engineering,
University of New South Wales,
Email billw at cse.unsw.edu.au
Phone: +61 2 9385 6876
Fax: +61 2 9385 4071
Last modified: 18 November 1996