Course Portfolio for Introductory Programming at University of Gloucestershire

cmedia | university |

Approaches to assessment

Purpose of assessment
Structure of assessment
Content of assessment
Assessment in semester 2 follow-on module
Role of labs in assessment
Plagiarism problems

Purpose of assessment: Assessment in the introductory programming modules has several aims and is not just concerned with assessing how well a student has achieved the learning outcomes. Students are often very driven by assessment, so the form of the assessment can be used to encourage regular attendance; enable formative feedback; give encouragement that progress is being made; encourage communication with teaching staff; encourage communication with each other and encourage critical thinking. Assessment that is too difficult can cause students to look for alternative approaches to passing the module, such as plagiarism. There is also a danger of over-assessment in our enthusiasm to help the students learn. The marks at level one do not count towards the final degree classification but are used to indicate whether a student can progress to the next level. This gives more freedom to experiment with different forms of assessment, as they are not as critical as in later years.

(top)

Structure of assessment: At Gloucestershire University, in the first semester, there are weekly exercise sheets to reinforce the taught material (see exercises4.doc for an example). Some are bookwork and others involve writing or amending small programs. One question from each worksheet counts towards the assessment. There is also a larger assessed task at the end of the semester. The marks are such that it is not possible to pass the module without attempting the final part of the assessment. The aim of the weekly sheets is to encourage attendance, give formative feedback and to build up confidence that progress is being made. There are two hand-in dates for the assessed worksheets so that written, more reflective feedback can be given. External examiners have frequently praised the level of feedback given in marked assignments. Unfortunately, the ones who might benefit most from the feedback are the ones least likely to pick up their assignments after marking.

(top)

Content of assessment: The programming exercises used are fairly standard - early ones involve some sort of calculation such as currency conversion or calculating a body mass index. I try to choose a calculation that is performed by some utility available from an Internet site - so that they can easily see how writing such an application may be useful and when they demonstrate their working program, they can use the site to help verify correctness of their own result. The more advanced students can gain extra marks by displaying the rounded result without using any built-in rounding facility.

Later exercises use a graphical class, the Turtle class, which draws straight lines of different thicknesses and colour. The final exercise asks students to create an animated screensaver on a particular theme (varied each year to reduce the possibility of plagiarism). This larger exercise gives students scope to be creative and go beyond what is taught in the module, if they wish. The requirement of animation increases the likelihood that students will use methods and parameters in their design (see CO102Assessment.doc the assessment brief for the final exercise). Here are one or two examples of student work related to the final assessment.

Student1: Code and Program
Student2: Code and Program

These were marked according to the following criteria.

(top)

Assessment in semester 2 follow-on module:The module in Semester 2 also uses weekly worksheets to guide students through an implementation of an object-oriented program containing two classes and a main method. The complete implementation is submitted in the middle of the semester but there is also a requirement to sign off a weekly progress sheet in order to encourage attendance and provide an opportunity for feedback. Students also have to demonstrate that their classes work using acceptance tests. In this case, the form of the assessment also mirrors professional practice by matching outcomes against parts of a specification. The user interface class is assessed by peer evaluation, encouraging communication between the students (see acceptanceTestsProgress.doc). The final Semester 2 assessment involves implementing a test harness to black-box test alternative implementations of a method. The students have to deduce the errors in the incorrect implementations and identify one that works correctly.

(top)

Role of labs in assessment: All students are supported in the labs and are given as much help as they need on the assessed exercises. In general, students who attend and ask for help should be able to pass the module. In an extreme case, this policy has resulted in a diligent student, with very little aptitude for programming, passing the module simply by persistently asking for help in the labs. The student was subsequently counselled not to continue with programming and readily accepted this advice. Unfortunately, it is more common for students with problems to stop attending and eventually fail.

(top)

Plagiarism problems: Plagiarism can be a problem, so assessed exercises are varied each semester. In the Semester 2 test harness exercise to black box test several different versions of a class, each student is given a different set of classes to test so that they cannot copy.

(top)

<-- Previous Next -->

 

©2006 Vicky Bush