Computer science degrees in the UK are graded through a system most students only half-understand until their final year — by which point the marks that matter most have already been decided. Unlike a pure exam subject, a CS degree mixes timed exams, programming coursework, lab practicals, group builds and a final-year project worth up to a third of your final year. And on top of your university’s own rules sits a second authority: the BCS, the Chartered Institute for IT, whose accreditation rules can decide whether your degree carries professional recognition at all.

This guide explains how computer science degrees graded in the UK actually work, layer by layer: what you are marked on in each module, how your yearly marks are weighted into a final classification, and the professional-body rules that override your university’s regulations in specific cases. It uses real programme rules from named universities — Birmingham, Leeds, Reading, Durham, Leicester, Kingston, Sheffield and others — so every claim below is grounded in a published regulation, not a guess.

The organising idea is simple. Your final degree class is produced by three layers: the module marks (how each assessment is scored), the classification algorithm (how years and credits are weighted), and the BCS accreditation rules (which can force outcomes your university’s own regulations would not). Miss any one layer and the other two will surprise you.

This guide explains how computer science degrees graded at UK universities actually work in practice.

Click Here: Final Grade Calculator UK

Layer One: What You Are Actually Marked On

The first thing to understand about how computer science degrees are graded is that “the exam” is only one instrument in a much larger toolkit. At the University of Reading, whose published programme specification is unusually explicit, “most modules are assessed by a mixture of coursework and formal examination. However, some modules are assessed only as coursework, while others are assessed solely by examination.” That sentence captures the CS assessment landscape at most UK universities: blended by default, with single-mode exceptions at both ends.

In practice, a CS student’s marks come from five or six distinct assessment types, each testing something different:

Assessment type	What it looks like in CS	What it rewards
Timed exams	Algorithms, theory of computation, maths for computing; usually 2 hours, some open-book or on-computer	Speed, recall, reasoning under pressure
Programming coursework	Individual coding assignments, often auto-tested against hidden test cases plus manual code review	Correctness, style, testing discipline
Lab practicals	Weekly supervised lab tasks — networks, operating systems, databases — marked in-session or by submission	Consistent weekly effort, practical fluency
Portfolios and reports	Design documents, reflective logs, technical write-ups accompanying a build	Communication, professional practice
Demos and vivas	Live demonstration of your software to examiners, sometimes with questioning	Understanding of your own system, composure
Group projects	Team software builds with shared and individual components	Collaboration — and provable individual contribution

The mix matters more than students expect, because each type has a different failure mode. Auto-tested programming coursework is brutally binary: your code either passes the hidden tests or it doesn’t, and a single misunderstood requirement can turn a week’s work into 30%. Exams in theory-heavy modules such as algorithms or formal languages reward the opposite skill — structured mathematical argument under time pressure. Students who are strong coders but weak exam-takers (and vice versa) will find their degree class shaped as much by the assessment mix of their chosen options as by their raw ability.

This is why option choice in years 2 and 3 is quietly a grading decision. A final year loaded with 100%-exam theory options plays to a completely different strength profile than one built around coursework-heavy applied modules and a big project. Neither is easier in any absolute sense — but one of them is easier for you, and the difference can be a full classification band.

Layer Two: How the Marks Add Up — The Weighting Nobody Reads

The second layer is the classification algorithm: how your university turns three (or four) years of module marks into one number. Almost every UK university gives later years more weight and first year little or none — but the exact ratios differ, and they change outcomes.

University	Weighting (Year 2 : Year 3)	Notable detail
Reading (BSc Computer Science)	1 : 2 (Part 2 = one-third, Part 3 = two-thirds)	At least 40% in the final-year project required for honours
Leicester	30 : 70 (Year 2 x 0.3, Year 3 x 0.7)	Borderline uplift rules apply on top of the weighted average
Norwich University of the Arts	25 : 75, or Year 3 only	Both calculations are run and the higher result is used

Three consequences follow. First, a weak second year is recoverable: at 25:75, a 55% Year 2 average needs only a 61.7% Year 3 average to reach a 60% final mark — a far smaller climb than most students assume. Second, the reverse is also true: a strong second year cannot carry a weak final year, because the final year dominates every one of these formulas. Third, Norwich’s “best of” rule is a genuine structural gift — if your Year 2 was poor, it can be discarded entirely. Check whether your own university runs an equivalent rule; many students never look.

The classification boundaries themselves are the standard UK honours scale: 70%+ for a First, 60-69% for a 2:1, 50-59% for a 2:2, and 40-49% for a Third. What varies is the algorithm that produces the number fed into those boundaries — and whether borderline cases get discretionary uplift, which is a separate decision made by the exam board. For how borderline discretion works in general, see our guide to degree classification algorithm changes, which covers how universities have been tightening these rules.

Worked Example 1: Priya’s 2:1 Push — When the Project Does the Heavy Lifting

Priya is in her final year of a BSc Computer Science at a university using a 25:75 weighting. Her Year 2 average was 62%. Her final year is built around a 40-credit individual project plus four 20-credit modules — the standard structure at Birmingham, Leeds and Reading, where the final-year project carries 40 of the year’s 120 credits.

Her marks: project 66%; modules 68, 64, 62, 62.

Step 1 — Year 3 credit-weighted average. The project is double the weight of a normal module:

(40 x 66) + (20 x 68) + (20 x 64) + (20 x 62) + (20 x 62) = 2,640 + 1,360 + 1,280 + 1,240 + 1,240 = 7,760
7,760 / 120 = 64.67%

Step 2 — Final degree mark.

(0.25 x 62) + (0.75 x 64.67) = 15.5 + 48.5 = 64.0% — a 2:1.

Now watch the lever work. If Priya’s project had scored 58% — exactly in line with her weaker modules — her Year 3 average would have been (40 x 58 + 80 x 64) / 120 = (2,320 + 5,120) / 120 = 7,440 / 120 = 62.0%, giving a final mark of 15.5 + 46.5 = 62.0%. Still a 2:1 — but the strong project lifted her two full percentage points, from the lower edge of the band to a comfortable position. On a 40-credit module, every extra 5 marks on the project is worth the same as 5 marks on two ordinary modules combined. If you are trying to improve a 2:2 into a 2:1 in your final year, the project is where the arithmetic is kindest to you.

The Final-Year Project: Your 40-Credit Lever

The individual final-year project is the single most grade-decisive element of most UK computer science degrees — and it is the element students most consistently underestimate. At Birmingham, the final year centres on a 40-credit “Computer Science Project” alongside four 20-credit options. At Leeds, the compulsory Individual Project is also 40 credits: “a substantial independent project under academic supervision.” At Reading it is SE3IP11, a 40-credit level-6 module. Durham’s COMP3012 Computer Science Project is 40 credits. The pattern is near-universal — though not quite universal: Kingston’s compulsory Individual Project (CI6600) is 30 credits, which still satisfies the BCS floor described below.

Why does the project carry so much weight? Three reasons. First, the arithmetic: at 40 credits it counts as much as two ordinary modules. Second, the marking: projects are assessed on the report, the implemented system, and often a live demo or viva — multiple components where a well-prepared student can accumulate marks steadily rather than gambling everything on one exam morning. Third, the supervision: you have a dedicated academic supervisor across the year, which means feedback loops that simply don’t exist for exam modules.

But the project also carries the strictest rules of any module on your degree. At Reading, a student “must obtain at least 40% in their project (SE3IP11) to be eligible for honours” — fail the project and the honours classification itself is off the table, regardless of your other marks. At Durham, the project “must be passed at 40% or above,” and a mark of 30-39% “cannot be compensated” — meaning the normal safety net that lets a weak module be carried by stronger ones does not apply. These are not quirks of two universities; they are the local expression of a national professional-body requirement, which is the third layer of the system.

Layer Three: The BCS Rules That Can Override Your University

The British Computer Society — the Chartered Institute for IT — accredits UK computing degrees, and its accreditation criteria reach directly into how your degree is graded. BCS can accredit programmes against the educational requirements for Chartered IT Professional (CITP), Chartered Engineer (CEng) and Incorporated Engineer (IEng) registration. The standard form of words you will see on course pages is that a degree is “accredited as partially meeting the educational requirement” for one of these registrations: the degree gives you the academic foundation, and professional experience plus further assessment completes the route. Sheffield’s BSc Computer Science page is a clean example — it states the course is BCS-accredited and “fully meets the requirements for Chartered Information Technology Professional (CITP) and partially meets the requirements for Chartered Engineer (CEng).”

Four BCS rules matter directly to your marks:

1. The project floor. Within an accredited undergraduate honours degree, the individual project must be “a piece of work of at least 30 credit points at level 6” — which is why 30- and 40-credit final-year projects are the norm. A degree without a substantial individual project at the right level cannot hold this accreditation.

2. The project must be passed without compensation. This is stated explicitly in the BCS accreditation guidelines, and it is the rule behind Durham’s “cannot be compensated” project regulation. Your university’s compensation scheme — the mechanism that lets a 35% in one module be offset by 65% elsewhere — is switched off for the project module. Fail the project and you must resit or resubmit it; no amount of strong performance elsewhere can carry it.

3. The first-attempt requirement (at some universities). Leicester’s programme specification states that “British Computer Society Accreditation requires that individual projects be passed at the first attempt,” and that students who exhaust their resit opportunities without passing are moved to the corresponding non-accredited BSc. Read that carefully: you can still graduate, but the degree you graduate with loses its BCS accreditation — which matters if you ever want the streamlined route to chartered status. Not every university applies the rule this strictly, but it shows how seriously accreditation conditions bite.

4. Accreditation is time-limited and conditional. BCS accreditation lasts a maximum of five years and can carry conditions — for example, that students take a specific module. Imperial’s joint Maths and Computing (JMC) degree publishes a striking example: students are only entitled to BCS accreditation if they pass the compulsory computing unit C271 plus at least two computing exams from a specified set and a designated maths option. Choose the wrong options and your degree is unaccredited even though you graduate from the same department. The lesson: on an accredited course, your module choices are also accreditation choices.

None of this means an unaccredited CS degree is a bad degree — many excellent courses choose not to seek accreditation, and employers hire overwhelmingly on skills and classification. But if your course advertises BCS accreditation, the rules above are part of your grading system whether you knew it or not.

Group Projects: When Your Mark Depends on Teammates

Most CS degrees include at least one assessed group software project — typically in the second year — and these are graded under a tension the BCS itself recognises: the work is collective, but the degree is individual. The BCS guidelines require that where a major assessed activity is a group enterprise, “the individual contribution of each student is measured against the learning outcomes.” Universities meet this requirement in different ways, and you need to know which one yours uses.

The common models are: a single shared group mark for everyone; a group mark for the product plus an individual mark for the process (report, presentation, or viva); or a group mark adjusted by peer assessment of contribution. The last of these is the most consequential. Researchers at UCL developed the IPAC methodology — Individual Peer Assessment of Contribution — specifically to solve this problem, and it combines peer ratings with the group mark in one of two ways: as an added percentage, or as a normalised factor that can raise or lower your individual mark depending on whether your contribution was above or below the group average.

In plain terms: under a normalised peer-assessment scheme, coasting doesn’t just feel bad — it is arithmetic. If the group product scores 70 but your peer-rated contribution factor is 0.85, your mark is 59.5. Conversely, carrying a weak group can lift you above the product mark. Bristol’s coursework documentation makes the expectation explicit: “your personal contribution will be evaluated and need to be demonstrated.” Keep evidence as you go — commit histories, design documents you authored, meeting notes — because contribution disputes are settled on evidence, not recollection. Our full guide to how group project marks work covers the moderation mechanisms in detail, and how university marking moderation works explains the second-marker and external-examiner checks that sit behind these marks.

Worked Example 2: Tom’s Failed Project — The Mark That Cannot Be Compensated

Tom scores 36% on his 40-credit final-year project. Under a Durham-style rule — the project “must be passed at 40% or above” and “a mark of 30-39% cannot be compensated” — Tom is in a specific, serious position: his other marks cannot carry the project, and he must resubmit it. The resubmission, under the standard UK resit rule, is capped at the pass mark: the best Tom can now score on the project is 40%.

Suppose Tom’s other final-year modules (80 credits) average 61%, and his Year 2 average was 58%, with a 25:75 weighting.

Step 1 — Year 3 average with the capped project:

(40 x 40) + (80 x 61) = 1,600 + 4,880 = 6,480
6,480 / 120 = 54.0%

Step 2 — Final degree mark:

(0.25 x 58) + (0.75 x 54.0) = 14.5 + 40.5 = 55.0% — a 2:2.

Now the counterfactual that shows the true cost. Had Tom passed the project first time at 62% — in line with his other modules — his Year 3 average would have been (40 x 62 + 80 x 61) / 120 = (2,480 + 4,880) / 120 = 7,360 / 120 = 61.33%, giving a final mark of 14.5 + 46.0 = 60.5% — a 2:1. The failed project didn’t just cost Tom marks; it cost him a classification band, because the 40-credit weight that makes the project a lever works in both directions. And note the harsher edge: at universities applying Leicester’s first-attempt rule, even a successful capped resubmission can mean graduating with a non-accredited degree.

Pass Marks, Compensation and Resits in CS

The baseline rules are the standard UK ones, but CS students meet their sharp edges earlier than most because of how project-heavy the degree is:

• Pass mark: 40% per module at undergraduate level. Below 40% is a fail; the 30-39% band is typically a “marginal fail” with its own rules.
• Compensation: most universities let you progress with a limited number of marginal fails (commonly up to 20-40 credits) if your overall average is strong enough. The project module is the standard exception — it must be passed outright, per the BCS rule.
• Resits are capped at 40%. A resubmitted project or resat exam can only ever return the bare pass mark, which is why Tom’s example above is so punishing: the cap applies to the module with the biggest weight on the degree.
• Progression thresholds have teeth. Reading’s regulations, for example, require threshold performance at each Part and stipulate that students progressing from Part 1 normally have “no module mark below 30% in any of the compulsory Part 1 modules” — so even a compensated fail in a first-year core module can block progression.
• You cannot resit a passed module to improve the mark. Resits exist to earn missing credits, not to polish a 58% into a 65%. If you want to lift your average, the lever is future assessments — above all the final-year project — not past ones. Students considering dropping their lowest module marks should check whether their university’s discounting rules apply before counting on them.

Project-Heavy vs Exam-Heavy: The Two Course Models

Step back from the regulations and a strategic picture emerges. UK computer science courses cluster around two assessment philosophies, and knowing which one you are on changes how you should allocate your effort:

	Project-heavy model	Exam-heavy model
Typical shape	40-credit final-year project, substantial coursework, demos and portfolios	Theory options assessed by timed exams, smaller project component
Where marks are won	Steadily, across the year — supervision feedback loops reward iteration	In concentrated bursts — revision season decides most of the class
Biggest risk	Slow-burn failure: drifting on the project until Easter, then discovering the scope is unachievable	Single-point failure: one bad exam morning in a 100%-exam module
Who it suits	Builders — students who learn by making and improve with feedback	Analysts — students who reason well under time pressure
Grading volatility	Lower: many components smooth out bad days	Higher: fewer, larger assessments

Most courses sit somewhere between the poles, but the direction of travel matters: a course whose final year is dominated by a 40-credit project plus coursework is graded more like an engineering portfolio than a mathematics exam series. The practical implication is about time allocation. On a project-heavy course, the highest-return activity in your final year is not extra revision — it is an extra supervised iteration on the project, because that is where the credit weight and the feedback loops coincide. On an exam-heavy pathway, the reverse holds: past papers for theory modules outperform marginal project polish.

Five Mistakes Computer Science Students Make About Their Marks

1. Treating first year as if it counts. At most universities the first year is zero-weighted for classification (it still matters for progression). Students who burn out chasing 75% in Year 1 and arrive exhausted in Year 2 have optimised the wrong year.

2. Starting the project in the second term. A 40-credit project begun seriously in January is a 40-credit project done at half the available pace. Supervisors allocate their attention early; the students who meet theirs weekly from October get the feedback loops that lift marks.

3. Assuming a resit resets the mark. It doesn’t — resits are capped at 40%, and on a 40-credit project that cap is a classification-band event, as Tom’s example showed. The safety net is thinner than it looks.

4. Coasting in group projects. Under peer-assessed contribution schemes, the group mark is only your starting point. Free-riding is not just unethical; it is arithmetically self-harming.

5. Confusing accreditation with chartered status. A BCS-accredited degree is the academic foundation for CITP or CEng — “partially meeting the educational requirement,” in the official phrase. Chartered status itself requires years of professional experience and assessment after graduation. The degree opens the door; it is not the destination.

Conclusion

How computer science degrees are graded in the UK comes down to three layers working together: the module marks earned across exams, coursework, labs and demos; the classification algorithm that weights your years into a single number; and the BCS accreditation rules that can override both — most sharply through the uncompensatable, first-attempt-sensitive final-year project. The students who navigate this system well share one habit: they read their own programme specification the way they would read a requirements document, because that is exactly what it is.

If there is one number to carry away from this guide, it is 40 — the credit weight of the final-year project at Birmingham, Leeds, Reading and Durham, the BCS minimum of 30 credits at level 6 that makes the project mandatory, and the 40% pass threshold below which the project cannot be carried by anything else. Aim your effort where the arithmetic is kindest: a strong project lifts every weighting formula, while a failed one drags all of them. Run your own numbers through the Final Grade Calculator UK or the Degree Classification Calculator before your final year begins — knowing what your project needs to deliver is the closest thing this system offers to a cheat code.