BSc

BSc Computing and Software Development

Computer science degree online UK. 8 assessed courses, 3,600 notional hours, tuition-free.

Online or on campus

36 months360 creditsEnglish

Overview

Computer science degree online UK. BSc Computing and Software Development at University of Brigant: 8 assessed courses, 360 credits and 3,600 notional learning hours, at 10 hours per credit. The hours on each course add up to that total. Seminars run online. An Edinburgh campus route is published separately from this online award. BSc Computing and Software Development is taught as one award, not a list of unrelated modules. The published length is 36 months, and the credit total is 360. Students move from Users, requirements, and a refusal through Users, requirements, and a refusal; Design and the interface; Build and review; Operations; Security and responsibility; Capstone: technical file, and finish on Honours file in Computing and Software Development. Each course has a question, a method, and a submission. In this field, students specify a small system, show how it was tested, and state how it fails. Reading is a specification, a test note, and an incident or post-mortem. The artefact a marker expects is a specification or reviewed component with tests and a trade-off note. The award is built so that a graduate can do the following in practice: Produce a professional file in Computing and Software Development Choose a method and write what the evidence cannot support Keep a record a third party can review Teaching assumes the student can read a source, attempt a problem before the seminar, and revise after feedback. Attendance at live seminars is part of the design. The capstone or final course must use the methods of the earlier courses; a project that ignores them does not pass. The pages for each course name the topics that are examined. Those topics are the syllabus. A brochure line is not a substitute for them.

Each credit is 10 notional learning hours. The courses add up to 360 credits and 3,600 hours.

Who This Programme Is For

People already working around Computing and Software Development
Career-changers who can study without leaving their city
Teams who need a file they can review, not a slogan

Faculty spotlight

University of Brigant supervises the courses and the final assessed file. Supervision is assigned from the school that owns the award.

How you can study

Recommended

Study online

100% tuition-free online

Online tuition is free. Online examinations are free. There is no exam fee for online study.

✦ Tuition: £0 / $0
✦ Examinations are free. There is no exam fee.
✦ Learn from anywhere · Live online seminars

Apply online →

On-campus study

Study at our campus

Prefer to learn at our Edinburgh campus? Campus tuition and campus examinations are charged. The published campus price is on each programme page.

✦ Tuition: £7,500 / US$9,500/year
✦ Location: 3 Lady Lawson St, Edinburgh EH3 9DS, United Kingdom
✦ Campus examinations are charged
✦ In-person seminars, library & student services

Apply for campus →

What You Will Learn

Produce a professional file in Computing and Software Development
Choose a method and write what the evidence cannot support
Keep a record a third party can review
State the limit of the award
Submit the final project inside the published hours

Curriculum

Stage 1 — 900 hours

Code	Course	Credits · hours
S131K01	Users, requirements, and a refusal Users, requirements, and a refusal (S131K01) is a 45-credit course on BSc Computing and Software Development, with 450 notional learning hours. By the end, students can specify a small system, show how it was tested, and state how it fails, using Users, requirements, and a refusal as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses a specification, a test note, and an incident or post-mortem. Seminar time is for the decision, not for reading the materials aloud. Assessment is a specification or reviewed component with tests and a trade-off note. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone. S131K01-M1 · Users, components, and the interface between parts — Users, requirements, and a refusal S131K01-M2 · Build, test, failure, and fix — Users, requirements, and a refusal S131K01-M3 · Deployment, logs, and recovery — Users, requirements, and a refusal S131K01-M4 · Trade-offs the designer must defend — Users, requirements, and a refusal S131K01-M5 · Security and failure in ordinary operation — Users, requirements, and a refusal S131K01-M6 · A supervised build or design with a defence — Users, requirements, and a refusal	45 · 450 h
S13VJ02	Design and the interface Design and the interface (S13VJ02) is a 45-credit course on BSc Computing and Software Development, with 450 notional learning hours. By the end, students can specify a small system, show how it was tested, and state how it fails, using Design and the interface as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses a specification, a test note, and an incident or post-mortem. Seminar time is for the decision, not for reading the materials aloud. Assessment is a specification or reviewed component with tests and a trade-off note. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone. S13VJ02-M1 · Users, components, and the interface between parts — Design and the interface S13VJ02-M2 · Build, test, failure, and fix — Design and the interface S13VJ02-M3 · Deployment, logs, and recovery — Design and the interface S13VJ02-M4 · Trade-offs the designer must defend — Design and the interface S13VJ02-M5 · Security and failure in ordinary operation — Design and the interface S13VJ02-M6 · A supervised build or design with a defence — Design and the interface	45 · 450 h

Code

Course

Credits · hours

S131K01

Users, requirements, and a refusal

Users, requirements, and a refusal (S131K01) is a 45-credit course on BSc Computing and Software Development, with 450 notional learning hours. By the end, students can specify a small system, show how it was tested, and state how it fails, using Users, requirements, and a refusal as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses a specification, a test note, and an incident or post-mortem. Seminar time is for the decision, not for reading the materials aloud. Assessment is a specification or reviewed component with tests and a trade-off note. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone.

S131K01-M1 · Users, components, and the interface between parts — Users, requirements, and a refusal
S131K01-M2 · Build, test, failure, and fix — Users, requirements, and a refusal
S131K01-M3 · Deployment, logs, and recovery — Users, requirements, and a refusal
S131K01-M4 · Trade-offs the designer must defend — Users, requirements, and a refusal
S131K01-M5 · Security and failure in ordinary operation — Users, requirements, and a refusal
S131K01-M6 · A supervised build or design with a defence — Users, requirements, and a refusal

45 · 450 h

S13VJ02

Design and the interface

Design and the interface (S13VJ02) is a 45-credit course on BSc Computing and Software Development, with 450 notional learning hours. By the end, students can specify a small system, show how it was tested, and state how it fails, using Design and the interface as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses a specification, a test note, and an incident or post-mortem. Seminar time is for the decision, not for reading the materials aloud. Assessment is a specification or reviewed component with tests and a trade-off note. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone.

S13VJ02-M1 · Users, components, and the interface between parts — Design and the interface
S13VJ02-M2 · Build, test, failure, and fix — Design and the interface
S13VJ02-M3 · Deployment, logs, and recovery — Design and the interface
S13VJ02-M4 · Trade-offs the designer must defend — Design and the interface
S13VJ02-M5 · Security and failure in ordinary operation — Design and the interface
S13VJ02-M6 · A supervised build or design with a defence — Design and the interface

45 · 450 h

Stage 2 — 900 hours

Code	Course	Credits · hours
S13LJ03	Build and review Build and review (S13LJ03) is a 45-credit course on BSc Computing and Software Development, with 450 notional learning hours. By the end, students can specify a small system, show how it was tested, and state how it fails, using Build and review as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses a specification, a test note, and an incident or post-mortem. Seminar time is for the decision, not for reading the materials aloud. Assessment is a specification or reviewed component with tests and a trade-off note. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone. S13LJ03-M1 · Users, components, and the interface between parts — Build and review S13LJ03-M2 · Build, test, failure, and fix — Build and review S13LJ03-M3 · Deployment, logs, and recovery — Build and review S13LJ03-M4 · Trade-offs the designer must defend — Build and review S13LJ03-M5 · Security and failure in ordinary operation — Build and review S13LJ03-M6 · A supervised build or design with a defence — Build and review	45 · 450 h
S14FI04	Operations Operations (S14FI04) is a 45-credit course on BSc Computing and Software Development, with 450 notional learning hours. By the end, students can specify a small system, show how it was tested, and state how it fails, using Operations as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses a specification, a test note, and an incident or post-mortem. Seminar time is for the decision, not for reading the materials aloud. Assessment is a specification or reviewed component with tests and a trade-off note. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone. S14FI04-M1 · Users, components, and the interface between parts — Operations S14FI04-M2 · Build, test, failure, and fix — Operations S14FI04-M3 · Deployment, logs, and recovery — Operations S14FI04-M4 · Trade-offs the designer must defend — Operations S14FI04-M5 · Security and failure in ordinary operation — Operations S14FI04-M6 · A supervised build or design with a defence — Operations	45 · 450 h

Code

Course

Credits · hours

S13LJ03

Build and review

Build and review (S13LJ03) is a 45-credit course on BSc Computing and Software Development, with 450 notional learning hours. By the end, students can specify a small system, show how it was tested, and state how it fails, using Build and review as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses a specification, a test note, and an incident or post-mortem. Seminar time is for the decision, not for reading the materials aloud. Assessment is a specification or reviewed component with tests and a trade-off note. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone.

S13LJ03-M1 · Users, components, and the interface between parts — Build and review
S13LJ03-M2 · Build, test, failure, and fix — Build and review
S13LJ03-M3 · Deployment, logs, and recovery — Build and review
S13LJ03-M4 · Trade-offs the designer must defend — Build and review
S13LJ03-M5 · Security and failure in ordinary operation — Build and review
S13LJ03-M6 · A supervised build or design with a defence — Build and review

45 · 450 h

S14FI04

Operations

Operations (S14FI04) is a 45-credit course on BSc Computing and Software Development, with 450 notional learning hours. By the end, students can specify a small system, show how it was tested, and state how it fails, using Operations as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses a specification, a test note, and an incident or post-mortem. Seminar time is for the decision, not for reading the materials aloud. Assessment is a specification or reviewed component with tests and a trade-off note. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone.

S14FI04-M1 · Users, components, and the interface between parts — Operations
S14FI04-M2 · Build, test, failure, and fix — Operations
S14FI04-M3 · Deployment, logs, and recovery — Operations
S14FI04-M4 · Trade-offs the designer must defend — Operations
S14FI04-M5 · Security and failure in ordinary operation — Operations
S14FI04-M6 · A supervised build or design with a defence — Operations

45 · 450 h

Stage 3 — 900 hours

Code	Course	Credits · hours
S145I05	Security and responsibility Security and responsibility (S145I05) is a 45-credit course on BSc Computing and Software Development, with 450 notional learning hours. By the end, students can map one named system, write a threat model, and specify the controls that would stop the most likely path, using Security and responsibility as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses control catalogues, incident write-ups, and a short technical standard. Seminar time is for the decision, not for reading the materials aloud. Assessment is a defensive design with a test plan and a statement of residual risk. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone. S145I05-M1 · Assets, trust boundaries, and the adversary model — Security and responsibility S145I05-M2 · Threat modelling and attack paths — Security and responsibility S145I05-M3 · Identity, logging, and segmentation — Security and responsibility S145I05-M4 · Detection, containment, and evidence — Security and responsibility S145I05-M5 · Residual risk and what a control does not stop — Security and responsibility S145I05-M6 · Defensive design, test plan, and after-action review — Security and responsibility	45 · 450 h
S14ZH06	Capstone: technical file Capstone: technical file (S14ZH06) is a 45-credit course on BSc Computing and Software Development, with 450 notional learning hours. By the end, students can specify a small system, show how it was tested, and state how it fails, using Capstone: technical file as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses a specification, a test note, and an incident or post-mortem. Seminar time is for the decision, not for reading the materials aloud. Assessment is a specification or reviewed component with tests and a trade-off note. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone. S14ZH06-M1 · Users, components, and the interface between parts — Capstone: technical file S14ZH06-M2 · Build, test, failure, and fix — Capstone: technical file S14ZH06-M3 · Deployment, logs, and recovery — Capstone: technical file S14ZH06-M4 · Trade-offs the designer must defend — Capstone: technical file S14ZH06-M5 · Security and failure in ordinary operation — Capstone: technical file S14ZH06-M6 · A supervised build or design with a defence — Capstone: technical file	45 · 450 h

Code

Course

Credits · hours

S145I05

Security and responsibility

Security and responsibility (S145I05) is a 45-credit course on BSc Computing and Software Development, with 450 notional learning hours. By the end, students can map one named system, write a threat model, and specify the controls that would stop the most likely path, using Security and responsibility as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses control catalogues, incident write-ups, and a short technical standard. Seminar time is for the decision, not for reading the materials aloud. Assessment is a defensive design with a test plan and a statement of residual risk. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone.

S145I05-M1 · Assets, trust boundaries, and the adversary model — Security and responsibility
S145I05-M2 · Threat modelling and attack paths — Security and responsibility
S145I05-M3 · Identity, logging, and segmentation — Security and responsibility
S145I05-M4 · Detection, containment, and evidence — Security and responsibility
S145I05-M5 · Residual risk and what a control does not stop — Security and responsibility
S145I05-M6 · Defensive design, test plan, and after-action review — Security and responsibility

45 · 450 h

S14ZH06

Capstone: technical file

Capstone: technical file (S14ZH06) is a 45-credit course on BSc Computing and Software Development, with 450 notional learning hours. By the end, students can specify a small system, show how it was tested, and state how it fails, using Capstone: technical file as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses a specification, a test note, and an incident or post-mortem. Seminar time is for the decision, not for reading the materials aloud. Assessment is a specification or reviewed component with tests and a trade-off note. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone.

S14ZH06-M1 · Users, components, and the interface between parts — Capstone: technical file
S14ZH06-M2 · Build, test, failure, and fix — Capstone: technical file
S14ZH06-M3 · Deployment, logs, and recovery — Capstone: technical file
S14ZH06-M4 · Trade-offs the designer must defend — Capstone: technical file
S14ZH06-M5 · Security and failure in ordinary operation — Capstone: technical file
S14ZH06-M6 · A supervised build or design with a defence — Capstone: technical file

45 · 450 h

Stage 4 — 900 hours

Code	Course	Credits · hours
S14PI07	Workplace project in Computing and Software Development Workplace project in Computing and Software Development (S14PI07) is a 45-credit course on BSc Computing and Software Development, with 450 notional learning hours. By the end, students can specify a small system, show how it was tested, and state how it fails, using Workplace project in Computing and Software Development as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses a specification, a test note, and an incident or post-mortem. Seminar time is for the decision, not for reading the materials aloud. Assessment is a specification or reviewed component with tests and a trade-off note. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone. S14PI07-M1 · Users, components, and the interface between parts — Workplace project in Computing and Software Development S14PI07-M2 · Build, test, failure, and fix — Workplace project in Computing and Software Development S14PI07-M3 · Deployment, logs, and recovery — Workplace project in Computing and Software Development S14PI07-M4 · Trade-offs the designer must defend — Workplace project in Computing and Software Development S14PI07-M5 · Security and failure in ordinary operation — Workplace project in Computing and Software Development S14PI07-M6 · A supervised build or design with a defence — Workplace project in Computing and Software Development	45 · 450 h
S15JG08	Honours file in Computing and Software Development Honours file in Computing and Software Development (S15JG08) is a 45-credit course on BSc Computing and Software Development, with 450 notional learning hours. By the end, students can specify a small system, show how it was tested, and state how it fails, using Honours file in Computing and Software Development as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses a specification, a test note, and an incident or post-mortem. Seminar time is for the decision, not for reading the materials aloud. Assessment is a specification or reviewed component with tests and a trade-off note. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone. S15JG08-M1 · Users, components, and the interface between parts — Honours file in Computing and Software Development S15JG08-M2 · Build, test, failure, and fix — Honours file in Computing and Software Development S15JG08-M3 · Deployment, logs, and recovery — Honours file in Computing and Software Development S15JG08-M4 · Trade-offs the designer must defend — Honours file in Computing and Software Development S15JG08-M5 · Security and failure in ordinary operation — Honours file in Computing and Software Development S15JG08-M6 · A supervised build or design with a defence — Honours file in Computing and Software Development	45 · 450 h

Code

Course

Credits · hours

S14PI07

Workplace project in Computing and Software Development

Workplace project in Computing and Software Development (S14PI07) is a 45-credit course on BSc Computing and Software Development, with 450 notional learning hours. By the end, students can specify a small system, show how it was tested, and state how it fails, using Workplace project in Computing and Software Development as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses a specification, a test note, and an incident or post-mortem. Seminar time is for the decision, not for reading the materials aloud. Assessment is a specification or reviewed component with tests and a trade-off note. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone.

S14PI07-M1 · Users, components, and the interface between parts — Workplace project in Computing and Software Development
S14PI07-M2 · Build, test, failure, and fix — Workplace project in Computing and Software Development
S14PI07-M3 · Deployment, logs, and recovery — Workplace project in Computing and Software Development
S14PI07-M4 · Trade-offs the designer must defend — Workplace project in Computing and Software Development
S14PI07-M5 · Security and failure in ordinary operation — Workplace project in Computing and Software Development
S14PI07-M6 · A supervised build or design with a defence — Workplace project in Computing and Software Development

45 · 450 h

S15JG08

Honours file in Computing and Software Development

Honours file in Computing and Software Development (S15JG08) is a 45-credit course on BSc Computing and Software Development, with 450 notional learning hours. By the end, students can specify a small system, show how it was tested, and state how it fails, using Honours file in Computing and Software Development as the working context rather than a generic management example. The course is taught in three movements. First, students establish the terms and the decision the course is about. Second, they apply the method to a case, dataset, text, or design and compare it with a weaker alternative. Third, they revise the work after feedback and state what the conclusion cannot support. Preparation uses a specification, a test note, and an incident or post-mortem. Seminar time is for the decision, not for reading the materials aloud. Assessment is a specification or reviewed component with tests and a trade-off note. A pass requires a clear method, evidence a marker can check, and an explicit limit. Credit is not awarded for summary alone.

S15JG08-M1 · Users, components, and the interface between parts — Honours file in Computing and Software Development
S15JG08-M2 · Build, test, failure, and fix — Honours file in Computing and Software Development
S15JG08-M3 · Deployment, logs, and recovery — Honours file in Computing and Software Development
S15JG08-M4 · Trade-offs the designer must defend — Honours file in Computing and Software Development
S15JG08-M5 · Security and failure in ordinary operation — Honours file in Computing and Software Development
S15JG08-M6 · A supervised build or design with a defence — Honours file in Computing and Software Development

45 · 450 h

Career Paths

Software developer
IT analyst
Cloud operations officer
Product analyst
Technical programme coordinator

Programme Highlights

360 credits · 3,600 notional hours · 8 courses
Course hours add up to the programme total
computer science degree online UK
Seminars run online. An Edinburgh campus route is published separately from this online award.

Assessment

Modules are assessed through a published mix of coursework, applied projects, and examinations. Exam windows are announced in advance so students in other time zones are not forced into overnight sittings. Alternative arrangements are available where documented.

Admission requirements

Academic entry

A secondary-school leaving qualification, or professional standing considered by admissions
Photo identification

Documents

A statement of about 400 words on why this award fits your work
A CV

Programme questions

How long is the BSc Computing and Software Development?

The published duration is 36 months. Teaching language: English. Actual time-to-complete depends on mode and any recognised prior learning.

Can I study this from my country?

You may study this award fully online from your country, or — where published — on campus at Brigant. Online study does not require a student visa. Campus study may.

What does it cost?

Degree tuition for this award is published as £0 / tuition-free on the online pathway. Examination or administrative fees may apply at checkout — never an annual tuition invoice. Check the Fees page for any extras.

What are the entry requirements?

Requirements are grouped on this page (academic, English, documents). Equivalent qualifications are considered. English may be waived after prior English-medium study.

How is the programme assessed?

Assessment is typically a mix of coursework, projects, and examinations. Doctoral awards include a thesis or dissertation and an oral examination. Details sit in the programme specification and module outlines.

Will this award be recognised where I live?

Recognition of the award for local employment, professional licence, or ministry attestation is decided by your employer or regulator. University of Brigant publishes verification pages for certificates. We do not claim automatic equivalence in every country.

How do I apply?

Start an application on this website. Progress is saved from the first step. Admissions: admissions@brigant.uk.

Recognised & Accredited

Ready to begin?BSc Computing and Software Development

Start an application

Loading…