A series of 6 individual tests. Each test contributes 1/6 of the 20% test mark.
You can complete each test as soon as it is released. The deadline for completing all of them is at the end of the module.
I recommend you do each quiz as the corresponding content is covered. Tests 1–4 cover the tools half of the module; tests 5 and 6 cover the group-project half. You can attempt each quiz as many times as you wish; your last attempt is the one that counts.
A mock coursework is available: here.
Solutions to the mock are here.
The coursework has 8 questions, each worth 5 marks, for 40 marks in total. That raw mark is then scaled to the 20% of the module mark that this component contributes.
The coursework for 2025/2026 can be downloaded available here.
In a small group you build a Python library that provides tools for a mathematical problem of your choice. A 'problem related to mathematics' is a deliberately broad brief: every example in the Example Group Projects listing is one valid answer, and your own project does not need to look like any of them. Every component is graded; you do not need to be the strongest coder in the group to earn full marks on the project, since the paper, the documentation, the tests, and the meeting minutes are all marked too.
In one sentence: 60% of your project mark comes from the marking criteria below (split as Communication 30%, Scope 50%, Research 20%), and the geometric mean with your engagement record then ties your individual mark to both your contribution and the group's output.
We combine two distinct components using a geometric mean:
where \(M \in [0, 100]\) is the individual measurable contribution score (in plain English, your engagement record: being present and contributing to the meeting, as evidenced by the minutes), and \(E \in [0, 100]\) is the shared effective contribution score (in plain English, the mark your group's submission gets). Both dimensions must be strong for a high final mark to be possible. A student who attends consistently but whose group produces weak work, or who free-rides on a strong group, cannot receive full credit.
M is individual, derived from the engagement record in each week's meeting minutes. The group submits one set of minutes per week during the contact hour; a different member acts as secretary each week (the group agrees the rota at its first meeting). The minutes record both who was present and what each member contributed, so M rewards meaningful participation, not just attendance: turning up without engaging does not score, and a member who was unwell but caught up through the week's minutes and asynchronous contributions can still be recorded as engaged.
A student's score is the fraction of the five group meeting weeks (Weeks 6 to 10) at which the minutes record them as having engaged:
The minutes template for each week is linked in the schedule.
E is shared equally among all group members. It is the mark awarded to the group project submission, assessed against the criteria below.
Three group-project marking scenarios (the free rider, the conscientious student in a struggling group, and a well-functioning group) are on a dedicated page; they are the clearest way to see why both \(M\) and \(E\) matter.
The various components of the submission should aim to demonstrate how the following aspects of the work have been addressed:
Typical description of mark:
Difficult to read and lacks a logical train of thought or argument. Very poor organisation and communication of work.
Poor style of writing with some parts difficult to follow. Poor organisation and presentation of material.
Satisfactorily written and presented with adequate technical content.
Well organised and clearly written with sound technical content. Results analysed and clearly presented.
Very well organised and clearly written with good technical content. Results assessed critically and arguments very well presented and supported. At the exemplary end of this band the paper would not look out of place in a Journal of Open Source Software submission, and the presentation lands the high-level idea, the design choices, and the limitations in 15 minutes without rushing.
Typical description of mark:
The work does not correspond to the project description.
The library includes documentation, some modular functionality and an attempt at automatic testing.
The documentation follows the Diataxis framework although it is poorly written. The code is modular but has a number of areas of improvement. The tests have been written and test some functionality of the code.
The documentation is clear. The code is written in a modular way with few areas of improvement. The tests confirm most functionality of the code and the documentation.
Well written documentation, code is modular and follows all conventions and guidelines covered in the course. The tests cover all functionality of the code and the documentation. At the exemplary end of this band the test suite includes edge cases that the tutorial does not exercise, and the README would be usable by someone outside the group with no extra help.
Typical description of mark:
No state of the field or references included.
An inaccurate state of the field included. Some poor references included.
An accurate state of the field included. Good references included but with little to no context and/or explanation.
A well written state of the field and good references with context and depth.
Outstanding state of the field demonstrating a great understanding not only of the library but of the already existing tools. The references are all of high quality and a thorough demonstration of understanding is given. At the exemplary end of this band the references are integrated into the prose, not relegated to a bibliography that the body never refers back to.
Note that this assessment has some overlap with the review criteria for the Journal of Open Source Software https://joss.readthedocs.io/en/latest/review_checklist.html. Some examples of papers written for that journal that can be helpful are:
Groups of four are in place by the time the group-project half of the module begins. Groups are self-selecting: form a group of four with people you want to work with and register it before the deadline. Any student who has not joined a self-selected group by the deadline is randomly assigned to a group with the other unassigned students. The incentive is straightforward: a self-selected group is one in which every member has chosen to engage, while a randomly assigned group is likely to contain other students who have not yet committed to the project.
At the first meeting the group agrees the secretary rota: a different member is secretary each of the five meeting weeks (Weeks 6 to 10), which spreads the minute-taking workload and gives each member a turn at documenting the work.
If a group member is unresponsive or disengaged for two consecutive meetings, raise it at the next meeting and record it in the minutes; the geometric mean already penalises lack of engagement, but flagging it early gives the rest of the group time to redistribute work and gives the disengaged member a chance to re-engage.
Your final submission should include the following 7 files. Every component is graded, so a strong submission needs strong work across all of them; you do not need to be the most experienced coder in the group to earn full marks if you have written the paper, drafted the README, or built out the test suite.
main.tex file: the source file for a 3 page paper written in
LaTeX.main.pdf file: the pdf file for a 3 page paper written in
LaTeX.<library>.py file: the
source file for your Python library.test_<library>.py file:
the test files for your Python library.README.md file:
the documentation for your Python library.presentation.mp4 (or similar file format): the video recording of
your 15 minute presentation.contribution.md file: a file describing the contributions of every
member of your group.The submission deadline is confirmed by the end of Week 2 of the module and posted on the schedule.
A set of worked example projects
is available. Each one is a small
Python library with the same files as your submission (library, tests,
README.md, and a short paper). They are written at the 'good'
level of the marking scheme, not the 'exemplary' level: read them as a
model of what a strong submission looks like, not as a ceiling.
Code generation tools (for example Large Language Models such as ChatGPT or Google Gemini) are increasingly capable of producing working programming code. These tools can sometimes generate high-quality solutions, but they can also produce incorrect, inefficient, or unsafe code.
The purpose of this module is for you to develop your own programming, problem-solving, and debugging skills.
For this coursework, you must submit your own original work.
You must not:
You may:
Automated code generation often produces recognisable artefacts. Where there is reasonable evidence that submitted work was generated using such tools, the submission may be treated as an academic integrity violation and penalties may apply.
This policy exists to ensure you develop the skills required for later modules and professional programming practice.