OCR A-Level Computer Science: Software & Systems — Complete Revision Guide (H446)
OCR A-Level Computer Science: Software & Systems — Complete Revision Guide
If processors and hardware describe the machine, software and systems describe everything that makes the machine usable. This module covers the layer of system software that manages the hardware on your behalf — the operating system and its core responsibilities — and the tools and methods used to write the application software that runs on top: the kinds of programming language, the translators that turn source into something executable, the methodologies that structure a development project, the object-oriented paradigm, and the testing and integrated development environment features that make programming tractable. It is the connective tissue between the bare hardware of module 1.1 and the algorithms and programming of the later courses.
In the H446 specification this material lives in module 1.2 (software and software development) and is assessed in Component 01: Computer Systems. The questions cluster into two recognisable families. The first asks you to describe the functions and management strategies of an operating system — memory management techniques, scheduling algorithms, the role of the OS as resource manager — often with a worked scheduling example. The second asks you to compare development concepts: high-level versus low-level languages, compilers versus interpreters versus assemblers, the suitability of a methodology such as the waterfall model or agile for a given project, and the principles of object-oriented design. The examiner consistently rewards precise terminology and the ability to justify a choice in context.
This is Course 2 of 11 on the LearningBro OCR A-Level Computer Science learning path. The course, Software & Systems, opens with system software and the operating system's responsibilities, develops memory management and scheduling, then turns to language types, translators, development methodologies, object-oriented design, and the practical craft of testing and IDE use. It builds directly on Processors & Hardware and feeds forward into Programming and the project-style thinking of Computational Thinking.
Guide Overview
The Software & Systems course is built as ten lessons that move from system software and the operating system through memory management and scheduling into the language and translator landscape, then development methodology, object-oriented design and the day-to-day craft of testing and IDE use.
- System Software
- Operating System Functions
- Memory Management
- Scheduling Algorithms
- Types of Programming Language
- Translators
- Programming Methodologies
- Object-Oriented Design
- Testing and Debugging
- IDE Features
System Software
The system software lesson establishes the categories of software and where the operating system sits within them. System software is the software that manages and maintains the computer system itself, as opposed to application software, which performs tasks for the end user. Within system software the lesson distinguishes the operating system, utility programs (such as disk defragmenters, compression tools, backup software and antivirus), library programs (collections of pre-written, pre-compiled routines that programs can call), and translators (the assemblers, compilers and interpreters developed in detail later).
A clean conceptual move that pays off across the module is to picture the layered model: hardware at the bottom, the operating system as the layer that manages the hardware and presents a consistent interface, system and application software above it, and the user at the top. This layering frames the operating-system functions covered next as the services the OS provides to everything above it, and it reappears when the translators lesson explains how source code becomes a program the OS can load and run.
Operating System Functions
The operating system functions lesson develops the OS as the resource manager that sits between applications and hardware. Its core responsibilities are process management (creating, scheduling and terminating processes), memory management (allocating memory to processes and reclaiming it), file management (organising files and directories and controlling access), input/output and peripheral management (handling devices through drivers and the interrupt mechanism), and security and user management (authentication and access control).
The lesson also introduces the families of operating system that H446 expects you to distinguish: a multi-tasking OS that gives the impression of running several programs at once by rapidly switching the processor between them; a multi-user OS that allows several users to share a system and schedules resources between them; a distributed OS that coordinates several networked computers to appear as one; a real-time OS that guarantees a response within a defined time limit (critical in the embedded control systems met in Processors & Hardware); and an embedded OS optimised for a dedicated device. The interrupt mechanism — a signal that causes the processor to suspend its current task, save its state, run an interrupt service routine, and then resume — is worth learning precisely, since it underpins how the OS responds to hardware events without constant polling.
Memory Management
The memory management lesson develops how the operating system shares limited physical RAM between processes, building directly on the primary storage concepts from module 1.1. Two techniques are central. Paging divides both physical memory and processes into fixed-size blocks — frames in memory and pages in the process — and maps pages to frames via a page table; because the blocks are a fixed size, any page can go in any free frame, which simplifies allocation but can waste a little space within the last page (internal fragmentation). Segmentation divides a process into variable-size logical units (a segment for the code, one for the stack, one for data) that reflect the program's structure; this matches the program's logic but complicates allocation and can leave gaps between segments (external fragmentation).
The lesson connects both to virtual memory: when the total demand exceeds physical RAM, pages or segments not currently needed are moved out to secondary storage and swapped back in on demand. The examinable risk is thrashing — when the system spends more time swapping pages between RAM and disk than doing useful work — which degrades performance sharply. Being able to explain the paging/segmentation distinction and the cause of thrashing is the core of the marks here.
Scheduling Algorithms
The scheduling algorithms lesson is the part of this module most likely to carry a worked calculation in Component 01. The CPU scheduler decides which ready process runs next, balancing throughput, response time and fairness. H446 expects you to know five algorithms and to be able to apply them to a set of processes with given arrival and burst times.
| Algorithm | Pre-emptive? | Basis | Key drawback |
|---|---|---|---|
| First Come First Served (FCFS) | No | Order of arrival | Long jobs delay short ones (convoy effect) |
| Shortest Job First (SJF) | No | Shortest burst time | Long jobs may starve; needs burst times known |
| Shortest Remaining Time (SRT) | Yes | Least time left | Overhead of frequent switching; possible starvation |
| Round Robin | Yes | Fixed time slice (quantum) | Performance depends heavily on quantum size |
| Priority Scheduling | Either | Assigned priority | Low-priority jobs may starve |
The transferable exam skill is to take a table of processes, apply the chosen algorithm step by step, and report the order of execution and the average waiting or turnaround time — so practise these calculations until the bookkeeping is automatic. Note especially the difference between pre-emptive algorithms (which can interrupt a running process when a more deserving one becomes ready) and non-pre-emptive ones (which run a chosen process to completion), and be ready to discuss starvation as the recurring fairness problem.
Types of Programming Language
The types of programming language lesson develops the spectrum from low-level to high-level languages and the major paradigms. Machine code is the binary the processor executes directly; assembly language is a human-readable one-to-one mapping onto machine code using mnemonics, requiring an assembler and tied to a specific processor architecture (a link back to the instruction sets in Processors & Hardware). High-level languages abstract away from the hardware with constructs closer to human language, are portable across architectures, and are translated by a compiler or interpreter.
The lesson then surveys the paradigms H446 names: procedural programming (sequences of instructions grouped into procedures), object-oriented programming (developed further in the object-oriented design lesson), declarative approaches, and the assembly-level programming that connects to little-man-style processor models. The examinable theme is the trade-off captured below: low-level code gives fine control and efficiency at the cost of portability and development effort, while high-level code gives productivity and portability at some cost in control.
| Property | Low-level (assembly/machine) | High-level |
|---|---|---|
| Closeness to hardware | Very close | Abstracted |
| Portability | Tied to architecture | Portable |
| Ease of writing | Difficult, verbose | Easier, expressive |
| Control over hardware | Fine-grained | Limited |
| Translation | Assembler | Compiler/interpreter |
Translators
The translators lesson develops the three programs that convert source code into executable form: the assembler, the compiler and the interpreter. An assembler translates assembly language into machine code on a one-to-one basis. A compiler translates an entire high-level program into machine code (or object code) in one pass before execution, producing a standalone executable; compilation is slower up front but the resulting program runs quickly and the source is not needed at run time. An interpreter translates and executes the source line by line at run time; this makes debugging easier and the program portable across any machine with the interpreter, but execution is slower and the source (or the interpreter) is needed every time the program runs.
| Feature | Compiler | Interpreter | Assembler |
|---|---|---|---|
| Input | High-level source | High-level source | Assembly |
| Translation unit | Whole program | Line by line | Whole program |
| Output | Executable/object code | Executes directly | Machine code |
| Speed at run time | Fast | Slower | Fast |
| Source needed to run? | No | Yes | No |
The lesson also covers the stages of compilation that H446 examines: lexical analysis (breaking source into tokens and building a symbol table), syntax analysis (parsing the tokens against the grammar and reporting syntax errors), code generation (producing machine or object code), and optimisation (improving the generated code for speed or size). Being able to describe what each stage does, and what kind of error it detects, is a recurring extended-answer requirement.
Programming Methodologies
The programming methodologies lesson develops the structured approaches to managing a software development project, and the suitability of each to a given scenario. The waterfall model proceeds through sequential phases — analysis, design, implementation, testing, maintenance — with each completed before the next begins; it is straightforward to manage and document but inflexible if requirements change late. Agile methodologies (including approaches such as extreme programming and rapid application development) work in short iterative cycles with continuous customer feedback, suiting projects where requirements evolve, at the cost of less up-front documentation.
The lesson also covers the spiral model, which repeats phases with explicit risk assessment at each iteration, suiting large, high-risk projects. The examinable skill is selection and justification: a project with stable, well-understood requirements and a fixed contract may favour waterfall; a project with uncertain or changing requirements and an available customer favours an iterative agile approach. Recognising which methodology fits the scenario, and explaining why, is the core of the marks — a reasoning move that recurs across Computational Thinking.
Object-Oriented Design
The object-oriented design lesson develops the paradigm that models a system as interacting objects, each bundling data (attributes) and the operations on that data (methods). The foundational vocabulary is the class (a template defining attributes and methods), the object (an instance of a class), and the constructor (the method that initialises a new object). Four principles are examined.
Encapsulation bundles attributes and methods together and restricts direct access to an object's internal state, usually by making attributes private and exposing controlled access through methods (getters and setters) — protecting data integrity. Inheritance lets a subclass acquire the attributes and methods of a superclass and extend or specialise them, promoting reuse and modelling "is-a" relationships. Polymorphism lets a method behave differently depending on the object it is called on, so a single interface can work with objects of different types. Abstraction exposes only the essential features of an object and hides unnecessary detail.
The lesson reinforces these with class-diagram conventions (showing classes, their attributes and methods, and inheritance relationships) and short illustrative class definitions. This material is the conceptual bridge to the practical object-oriented work in Programming, and the design discipline it teaches — modular, reusable, well-encapsulated code — is exactly what the testing and debugging lesson relies on.
Testing and Debugging
The testing and debugging lesson develops how software is verified and how defects are located and removed. H446 distinguishes the strategies. Black-box testing checks behaviour against the specification without knowledge of the internal code, using carefully chosen test data; white-box testing uses knowledge of the internal structure to ensure every path and branch is exercised. Alpha testing is carried out in-house before release; beta testing is carried out by real users in real conditions before final release.
The lesson stresses the design of test data — normal data (typical, valid values), boundary data (values at the edges of the acceptable range, where off-by-one errors hide), and erroneous data (invalid values that should be rejected) — because the choice of test data is a recurring exam item. It distinguishes the classes of error: syntax errors (violations of the language grammar, caught at compilation as in the translators lesson), logic errors (the program runs but produces the wrong result), and runtime errors (failures during execution such as division by zero). Debugging then uses the IDE tools — breakpoints, single-stepping, watches — covered next to trace a logic error to its source.
IDE Features
The IDE features lesson develops the integrated development environment as the tool that brings editing, translation and debugging together to support the programmer. The features H446 expects you to describe and justify include a source-code editor with syntax highlighting and auto-indentation; autocompletion and prettyprinting that speed accurate entry; a built-in translator (compiler or interpreter) for running and testing code; and debugging tools — breakpoints that pause execution at a chosen line, single-stepping that runs one line at a time, variable watches that display values as the program runs, and a stack trace that shows the chain of calls when an error occurs.
The examinable theme is how each feature reduces a specific class of error or speeds a specific task: syntax highlighting and autocompletion reduce syntax errors; breakpoints and watches make the logic errors of the testing and debugging lesson tractable to find; the integrated translator shortens the edit-run-test loop. Being able to name a feature and state the development problem it solves is precisely what earns the marks.
How to Revise Software & Systems
The highest-yield revision targets on this module are the comparison and calculation items. Build a one-line distinction for each examined pair — compiler versus interpreter, paging versus segmentation, waterfall versus agile, black-box versus white-box, pre-emptive versus non-pre-emptive scheduling — and rehearse them until you can produce the discriminator instantly, because Component 01 almost always asks you to justify a choice rather than recall a property in isolation. Then drill the scheduling algorithms on worked process tables until the waiting-time and turnaround-time bookkeeping is automatic; this is the most mechanical and therefore most reliably scorable part of the module.
For the operating-system and OOP content, structure your notes around the four headings the examiner uses: the OS as resource manager (process, memory, file, device, security), and the four OOP principles (encapsulation, inheritance, polymorphism, abstraction), each with a one-sentence definition and a concrete example. Pair that with the stages of compilation and the classes of error, and you have the full recall spine of the topic.
Start at the Software & Systems course and work through all ten lessons in order, from system software to IDE features. Once the operating system, the translator pipeline and the object-oriented paradigm are fluent, the practical Programming course and the project thinking of Computational Thinking on the OCR A-Level Computer Science path become applications of the systems understanding you have just built.