Assessment details and criteria for PGT students#

The assessment for PGT students will consist of two parts:

  1. a short viva ~ 5-10 mins (20%)

  2. the project submission (45%)

The short viva: (5-10 mins) with members of staff will be held during the 9th week of the course. It will concern your project as it currently is (we understand you will not have finished it at this point, but please ensure an up-to-date version of the project is available at the end of the previous week). The only preparation necessary for this viva is to ensure you are familiar with your project. The viva will take the form of a code review. You’ll be asked questions about your code, design decisions and alternative approaches you might have taken. The project submission: projects must be submitted in their final form by 5pm on SUBMISSIONDATE. In assessing the projects we will be looking at the following features:

  • Does it show a good grasp of python?

  • Does the code tackle the stated scenario well?

  • Is there evidence of self-driven learning (e.g incorporating relevant new modules)?

  • Does it demonstrate a novel approach to the stated problem?

  • Is the code “clean” and appropriately documented and therefore easy to follow?

  • Does it evidence good design decisions in the way it is structured?

  • Does it have a set of appropriate tests?

  • Does the description in the accompanying markdown / report indicate an ability to explain what is being done and why?

Choosing a project scenario#

Whilst we ask you to come up with a scenario for your project, we are not assessing this directly, and don’t want you to be too concerned about what you choose. Any sensible scenario that provides a direction / goal for your project and a non-trivial problem to solve is acceptable. We ultimately would like you to pick something that you think would be fun and interesting to work on, and fires your imagination. Hopefully reading through the examples next to each project will demonstrate what we mean, but if you are still concerned please discuss this with us early on.

GUIs#

You may if you wish add interactive elements to your project. This may include a gui. Students have sometimes got carried away with this and spent too much time on it. GUIs can look very impressive but often they represent lots of repetitive code. Particularly in a world of AI this doesn’t equate to large increases in a student’s project mark. Our main aim in marking is to look at what students can demonstrate they have learnt across the breadth of the course. A gui can be helpful for the end user to interact with your code, but we recommend keeping it simple and focussing on the organisation, functionality and data manipulation aspects of your code.

Use of AI tools#

AI tools such as ChatGPT are allowed to be used in the course of your project. If you use AI tools to generate code, you must ensure that you understand how it works at all scales. The Viva will be an opportunity to demonstrate this understanding. If you use AI tools, you must also ensure that you do not violate any copyright or licensing restrictions. You should also be aware that AI tools can sometimes generate code that is incorrect or insecure, so you should always review and test any code generated by AI tools before using it in your project.

Viva – 20% of module grade#

80+% They can articulate both the way in which their code works and the reasons for choosing such an approach with superb clarity. When asked questions about their code they are adept in explaining the particulars and logic of small sections and the overview high-level design decisions made. They can extremely clearly reason about alternative approaches they may have taken, other projects that could be solved and how, and outline the pros and cons.

60+% They are able to explain how their code works, and the reasons for choosing such an approach in a comprehensible way (though follow up questioning might be required to draw this out). When asked questions about their code they can explain logic of small sections and why the code is organised in a particular way. With some prompting, they can reason about alternative approaches they may have taken, outline the pros and cons or suggest how their code might be applied to a related problem.

40+% It is hard to understand from the explanations given how the code works at either small or larger scale. It is not always obvious that the student understands it well. They struggle to suggest how things might have been done differently or the code applied to a different but related problem.

Code submission - 45% of module grade#

80+% Excellent code, which addresses the (sufficiently meaningful) problem identified in the scenario in a readable, efficient and elegant manner, making excellent use of appropriate Python language elements and modules. If the implementation is incomplete, this is clear.

60+% Good code, which mostly addresses the (sufficiently meaningful) problem identified in the report in a fairly readable and efficient manner, making use of appropriate Python language elements and modules. It is reasonably clear where the implementation is incomplete.

40+% Poor code, which barely addresses the (possibly rather simplistic) problem identified in the report, in a manner that is difficult to comprehend and possibly very inefficient. Poor use of appropriate Python language elements and modules.