|
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 or
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
|
