TEACH MSC.PROJECT.CHECKLIST                       Aaron Sloman Jan 2001

CHECKLIST FOR AI MINI-PROJECTS : MSc Cognitive Science or AI Stream

Name of student:

Project topic:

PLEASE NOTE: This checklist indicates strengths and weaknesses of your
mini-project taken into account in assigning a mark. No simple algorithm
is used for deriving marks from this because examiners use judgement in
allocating different weights to different dimensions when marking
projects that are very different in character. The marks are provisional
and subject to modification by external examiner and exam board.
=======================================================================

1. Overall structure of the report (including division into sections,
provision of table of contents, concluding section, appendices, etc.)
Very good() good() acceptable() poor () very bad()


2. Introductory overview of project aims, achievements, ontology,
motivation. Is the project related to any AI literature (e.g.
related work in AI textbooks?)
Very good() good() acceptable() poor () very bad() missing()


3. Description of program structure. Analysis of what the program
does, how it does it, clear separation of levels of description, and
separation of description of WHAT procedures do from explanation of
HOW they do it. Good use of diagrams (where appropriate).
Very good() good() acceptable() poor () very bad() missing()



4. Concluding section, including discussion of what has and hasn't been
achieved and possible further developments. Is there a critical
evaluation (by student) of results of the project?
Very good() good() acceptable() poor () very bad() missing()


5. Instructions (e.g. in appendix) on how to run the program, including
correct file names, etc.
Good() acceptable() poor () very bad() missing()


6. Spelling, grammar, punctuation: Good() acceptable() poor ()

7. Layout of the report/dissertation (formatting, diagrams, table
of contents, etc. -- Did the student read the instructions?)
Good() acceptable() poor () very bad()

8. Physical presentation (e.g. loose and scrappy bits of paper, vs
nicely packaged and bound report). Good() acceptable() poor ()

9. Examples of programs running, with annotations, and without
excessive use of trace printing:
Good() acceptable() poor () very bad() missing() Not applicable()


10. Intrinsic difficulty of project, need for originality, need to
define difficult procedures, need for complex interface code, etc.
Was it more than a repetition of a teach file?
Very high() high() medium() low()


11. The final program -- overall functionality. Does it do something
intresting?  Are there merely partially debugged fragments?
Very good() good() acceptable() poor () very bad()
The program works () --- doesn't work ()


12. Quality of code, including use of global variables, structure,
choice of data-types, modularisation, clarity, maintainability,
division into sections, etc.
Very good() good() acceptable() poor () very bad()


13. Are there adequate comments (e.g. use of ENTER procheader)?
Very good() good() acceptable() poor () very bad()

14. Bibliography. Signs of reading AI literature?
Good() acceptable() poor () missing() Not applicable()

15. Table of contents: is it accurate? Does it include appendices?
Good() acceptable() poor () missing() Not applicable()

16. Description of program testing. Tests in source code.
Good() acceptable() poor () very bad() missing() Not applicable()

17. In group projects: explanation of who did what:
Good() acceptable() poor () missing() Not applicable()
=======================================================================
Marker's signature:                         Date:

Any further comments:


















    Pass: 40; Fair 50-59; Good: 60-69
    First class: 70-100; Outstanding: 80-100
--- $poplocal/local/teach/msc.project.checklist