The students submit their labs using CATE. The submission deadline is Monday evening at midnight. The submissions are then passed to first year lab and autotested. You should receive the autotested submissions on Tuesday morning your email. You should then print the submissions and mark them ready for returning to the students at the next PPT meeting. You can use the command "apr_paged" for formatting and printing the submissions if you wish.
By the next PPT meeting. Timing is vital to the success of lab in helping students learn to program. It is the rapid feedback that allows the department to teach programming in such breadth and depth. The lab exercises have to keep synchronised with the lecture courses so that the programming constructs are fresh; the labs should be marked and returned at the next PPT meeting so that the feedback given can make a direct impact. This means that you will only have a few days between receiving a submission and reurning a marked piece of work. You will need to set aside time each week to ensure that you have time to mark the student submissions.
You should refer to the mark schedule on the lab specification to see how the marks are divided between the different parts of the exercise. Generally the marks are divided between those given for correctness and testing (i.e. passing the autotest) and those for design, style and readability. Ther are marks for both for correctness and style. This division between these two elements is not rigorous but we want to emphasise the importance of good design when programming. We want the students to reflect on the process of designing and writing a program and the marks and comments should encourage students to do this.
The mark schedule is given at the end of the lab specification and it should give a general idea of how the marks for a lab exercise should be allocated. The various headings given "Design, Style, Readability" and "Correctness and Testing" are not mutually exclusive. The headings indicate the importance given to program design (the use of simple algorithms, the use of modularisation etc.), style (neatness, good layout, economy etc.), readability (are there signposts such as comments, meaningful identifier names etc. that allow another programmer to read through the code and understand it easily) and testing (did the student incorporate testing in the design process and thoroughly test and debug their program before submission). "Correctness" is connected to the question answered by the autotest - does the program meet its specification? - and this is why only some marks are allocated purely for correctness. A program can pass the tests given in the autotest but still be poorly designed. However it is more usual that programs fail some of the autotest cases due to design faults. Did the program design mirror the problem? Did the student incorporate testing in the writing process? Was the program error partly the result of badly named identifiers or too complex a structure? Putting an emphasis on "Design, Style, Readability" means that lab marking is an art not a science. However the marks should be reasonably consistent given the aims for each exercise.
The script should contain a mark both for "Correctness and Testing" and "Design, Style and Readbility" as described in the lab specification. You should mark out of 5 for correctness and a mark of 5 for style and sum these to give a mark out of 10 to be entered into CATE. The returned work must bear a letter grade A..F (see the tutorial support page for a translation from numerical marks to letter grades). Students should get good marks for both of these heads. When you enter these marks into CATE you should add them together. The mark should give the student information about their general progress with programming. In particular they should give the student a reasonable idea of how well they are likely to do in the online tests. which they need to pass if they are to continue to the second year. The script should also be extensively and comprehensively annotated with an indication of the quality of the program and how it could be improved. The annotations are very important as they constitute part of a dialogue with the student. You should expect that any comments should be taken on board and acted upon in subsequent labs. If a student has not taken on your criticisms of their programming methods you can deduct marks in subsequent submissions. You also need to give your students encouragement when you are marking.
Each lab consists of a programming problem that can be solved using programming constructs taught recently in the associated lecture course. Students are also expected to develop general skills in program design as they gain more experience. The mark given should give the student information about their general progress with programming. In particular they should give the student a reasonable idea of how well they are likely to do in the online tests and whether In particular it should give the student an idea about whether they need to work more on programming to do well in the tests. If you have made a comment on a previous lab exercise about a programming error and the student continues to make the same error you may wish to deduct marks. Hopefully the marks should serve to encourage students as mostly they will solve the problems well and they will see that they are making incremental progress.
The feedback given to a student on their lab submission via annotations is the most important part of lab assessment. We give more detailed guidance elsewhere for marking for "Design, Style, Readability and Testing" but the purpose of your comments is to get the students to reflect on the programming process. As they have thought about the program when they wrote it your comments will have a very direct impact. You should ask - how did the student write this program - could they have written it in a better way? If the student has used a good design methodology you should comment this - if not you should indicate how they could improve. Many problems are fairly simple (too many identifiers, over complex control structures etc.) whilst others are more subtle and relate to the way they analysed the problem (poor data design etc.). Your comments should be used as a basis of a discussion of the students submissions but you should also use them to communicate your expectations to the student. In future submissions they should have applied your comments and if they do they should be able to do well in the online tests. You should also use your feedback to encourage students - especially if they have adopted your comments and are making improvements.
Marking for correctness involves reading the autotest and looking at the individual test cases. If a program has failed a test case you should examine the program to see where and why the error occured. Usually this is fairly straightforward if you follow the program logic. You can then comment the program to show the error and its source. If the program fails the autotest this can be seen as an indication that it was not adequately tested. Using the autotst results to mark work for correctness of course requires interpretation and you should always refer back to the student's program and the mark schedule when marking for correctness.
Marking for correctness may indicate problems with the above but you should check the program as a program can pass the autotest even though it was not well designed, was not written with good style, was not commented and unclear. Although you may have additional ideas about Design Style and Readability some notes as to what to look for can be found here.
Late submissions and missed submissions should be handled by the PPT. CATE has been modified to accept submissions up to a week late without the student requesting an extension in advance. We can mark work that is a few minutes late without asking for an explanation from the student involved. However in all other cases we will want the student to contact either their PPT or First Year Lab Organiser to give an explanation about why their submission was handed in late. We have no obligation to mark late submissions. The First Year Lab Organiser and PPT will deal with each individual case on its merits. It is the First Year Lab Organiser who makes the decision whether to accept a late submission for marking.
If your PPT or either the First Year Lab Organiser or the Senior Tutor has agreed to accept a late submission you should mark it in the usual way.
Missed submissions are taken very seriously as we expect students
to complete all the lab exercises set.
This is because the labs form an integrated course and any
current lab exercise builds on the work done in previous labs.
The loading and timings of the labs and courseworks are carefully
designed so that they are evenly distributed.
If a student starts to miss submissions or
hand lab and coursework in late this can have knock on effects.
A student will fall further behind if they skip lectures and
tutorials to catch up on missed submissions.
Missed submissions are usually a good indication of more general
problems.
It is much better if a student submits a partial solution if
they haven't completed the entire lab exercise.
We can then give feedback and help to the student on the
basis of their submission.
You need to discuss any missed submissions with your PPT.
Generally if a student has missed more than one submission
it will be necessary to get the Senior Tutor Margaret
Cunningham involved as well and she will call in the student
to discuss any problems they may have.
The Driving Tests (which give the students practice for the Final Lab
Tests (lab exams) take place (in term 1) in weeks 5 and 6 for Haskell
and in week 11 for Kenya/Java.
Students who fail the Kenya/Java driving test have to attend additional
problem solving classes in term 2 and they will then
do a resit towards the end of
term 2.
A Java O-O
Driving Test will be scheduled for week 10 of term 2.
After this they will hopefully pass the Kenya/Java Final Lab test
(done in week 11 of term 2).
The Final Lab Tests (lab exams)
take place (in term 2) in week 1 for Haskell and
week 11 for Kenya/Java. The students will do a Prolog Final Lab Test
in term 3.
A Java O-O test will also be scheduled for the beginning of term 3.
The students will do a Prolog test in term 3.
The Final Lab Tests assess the programming skills acquired by the
students in the course of attending lectures, tutorials, labs, PPT
meetings etc.
They measure a students ability as a programmer.
The students have to pass the Final Lab Tests to continue
to the second year.
You should use the tutorial support system as described in the UTA introductory page.