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

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 deserves precise treatment because it is examined in its own right and underpins device management. An interrupt is a signal — from hardware (a key press, a disk transfer completing, a timer) or software (an error, a system call) — that a device or process needs the processor's attention. The processor does not check for interrupts mid-instruction; it completes the current fetch-decode-execute cycle, then, at the interrupt checkpoint, tests whether any pending interrupt outranks the current task's priority. If so, it pushes the current register contents (including the program counter) onto a stack, loads the address of the relevant interrupt service routine (ISR) from the interrupt vector, runs the ISR, and then pops the saved registers to resume exactly where it left off. Priorities matter: a higher-priority interrupt can itself interrupt an ISR, and the stack is what makes this nesting safe. The whole point is efficiency — the processor responds to events only when they occur, instead of wasting cycles constantly polling every device to ask whether it needs service.

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).

Worked example: translating a logical address under paging

Paging is easier to explain with a concrete address. Suppose pages are 1 KB (1024 bytes) and a process generates the logical address 5000. The OS splits this into a page number and an offset within the page:

$\text{page number} = \left\lfloor \frac{5000}{1024} \right\rfloor = 4, \qquad \text{offset} = 5000 \bmod 1024 = 904$

The page table for this process maps logical page 4 to, say, physical frame 9. The physical address is then the frame's base plus the offset:

$(9 \times 1024) + 904 = 9216 + 904 = 10120$

Two ideas fall out of this. First, because every page is the same fixed size, any page can be placed in any free frame — that is what makes paging simple to allocate, and it is why paging suffers only small internal fragmentation (wasted space inside the last, partly-filled page) rather than the external fragmentation (gaps between variable-sized blocks) that plagues segmentation. Second, the offset is never translated — only the page-to-frame part is looked up — which is why the page size determines how many bits the offset occupies. An exam question that gives you a page size and a logical address is asking for exactly this divide-and-remainder, so show both parts of the split.

The lesson connects both techniques 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. Thrashing typically sets in when too many processes are competing for too little RAM, so each keeps evicting pages the others immediately need back. Being able to explain the paging/segmentation distinction, translate a logical address, and give 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.

Worked example: FCFS versus SJF on the same processes

Nothing embeds these algorithms like running two of them over identical data. Take four processes that all arrive at time 0, with the burst (CPU) times below, and compute waiting time (how long a process sits ready before it first runs to completion) and turnaround time (arrival to completion).

Process	Burst time
P1	8
P2	4
P3	9
P4	5

First Come First Served runs them in arrival order P1 → P2 → P3 → P4. Each process starts when the previous one finishes, so the completion times are 8, 12, 21 and 26. Waiting time is the start time (arrival is 0), giving P1 = 0, P2 = 8, P3 = 12, P4 = 21:

$\text{average waiting} = \frac{0 + 8 + 12 + 21}{4} = \frac{41}{4} = 10.25$

Shortest Job First reorders by burst time: P2 (4) → P4 (5) → P1 (8) → P3 (9). Completion times are 4, 9, 17 and 26, so waiting times are P2 = 0, P4 = 4, P1 = 9, P3 = 17:

$\text{average waiting} = \frac{0 + 4 + 9 + 17}{4} = \frac{30}{4} = 7.5$

SJF produces the lower average waiting time — that is a provable property of SJF for a fixed set of jobs, not a coincidence. The examinable trade-off is that SJF requires the burst times to be known in advance (rarely true in practice, so they must be estimated) and that a steady stream of short jobs can leave a long job waiting indefinitely — starvation. FCFS never starves anything but suffers the convoy effect, where one long job at the front delays every short job behind it. Writing out the completion-time line and then subtracting is the reliable method; the most common mistake is to confuse waiting time (excludes the process's own burst) with turnaround time (includes it).

Worked example: Round Robin and the quantum

Round Robin is pre-emptive: each process gets the CPU for a fixed time quantum, then is moved to the back of the ready queue if it is not finished. Using the same four processes with a quantum of 4, execution proceeds P1(4) → P2(4, done) → P3(4) → P4(4) → P1(4, done) → P3(4) → P4(1, done) → P3(1, done). Notice how the responsiveness improves — P2 finishes early and no single process monopolises the CPU — at the cost of extra context switches, each of which has overhead as the OS saves and restores process state. The quantum is the tuning dial: too large and Round Robin degenerates towards FCFS; too small and context-switch overhead dominates. "Discuss the effect of quantum size" is a classic six-mark item, and the answer is exactly this two-sided tension.

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. A useful discriminator: lexical analysis removes whitespace and comments and turns the source into tokens; it does not check that the tokens form a valid statement — that is syntax analysis. So a misspelled keyword may survive lexing as an identifier token and only be caught during parsing.

Intermediate code and virtual machines

A third route sits between pure compilation and pure interpretation, and H446 expects you to recognise it. Some languages compile source into intermediate code (also called bytecode) — a compact, platform-independent instruction set that is not the native machine code of any real processor. That bytecode is then run by a virtual machine (VM): a program that emulates a processor and executes the intermediate code, interpreting it (or just-in-time compiling it) on whatever real hardware it happens to be running on.

The pay-off is portability with a head start on performance. Because the bytecode is the same everywhere, "compile once, run anywhere" holds — you ship one bytecode file and any machine with the matching VM can run it, without recompiling for each architecture. Because much of the lexical and syntax work was already done at compile time, the VM has less to do at run time than a raw source interpreter. The cost is a layer of indirection: bytecode running on a VM is generally slower than fully native compiled code, and the VM itself must be present on the target machine. This is the classic "portability versus raw speed" trade-off, and naming intermediate code plus the VM that executes it is what earns the marks on a question about how a language achieves platform independence.

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.

A short, concrete illustration ties the four principles together. Consider a base class and a subclass:

class Animal:
    def __init__(self, name):
        self.__name = name        # encapsulation: private attribute

    def get_name(self):           # controlled access via a getter
        return self.__name

    def speak(self):
        return "some sound"

class Dog(Animal):                # inheritance: Dog is-an Animal
    def speak(self):              # polymorphism: overrides speak()
        return "Woof"

Every principle is visible here. Encapsulation: __name is private and reached only through get_name(), so outside code cannot corrupt it directly. Inheritance: Dog acquires the constructor and get_name() of Animal without repeating them. Polymorphism: calling speak() on a Dog gives "Woof" while the same call on a plain Animal gives "some sound" — one interface, behaviour that depends on the object's actual type. Abstraction is the design decision to expose only speak() and get_name() as the public interface while hiding how the name is stored. A frequent exam slip is to describe inheritance and polymorphism as the same thing; the distinction to state is that inheritance is about acquiring members from a superclass, while polymorphism is about a single method behaving differently depending on the object it acts on.

The lesson reinforces these with class-diagram conventions (showing classes, their attributes and methods, and inheritance relationships as arrows from subclass to superclass). 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.

Exam Technique: Scoring the Software & Systems Questions

Treat scheduling questions as bookkeeping, and show the schedule. For any scheduling calculation, first write the execution order, then a line of completion times, then subtract to get waiting or turnaround. Marks are awarded for the method as well as the final average, so an examiner who can see your completion-time line will credit the working even if one subtraction slips. State clearly which algorithm you are applying and, for Round Robin, the quantum you are using.

On "compare" questions, pair the two sides on every axis. Compiler versus interpreter, paging versus segmentation, waterfall versus agile, black-box versus white-box — a comparison answer must set the two against each other point by point ("a compiler translates the whole program before execution, whereas an interpreter translates line by line at run time"). Two disconnected descriptions score far below a genuine comparison.

Match the methodology to the scenario's clues. Methodology questions embed the answer in the scenario: "requirements are fixed and fully known" points to waterfall; "the customer is available and requirements will evolve" points to agile; "large, high-risk, needs risk review each cycle" points to spiral. Quote the clue from the scenario and then name the methodology it implies — that is the AO3 application move.

Define OOP terms with a concrete example, not just a definition. "Encapsulation restricts access to an object's data" is a start, but adding "for example, making an attribute private and exposing it through a getter method" turns a definition mark into a definition-plus-application mark.

Common Mistakes to Avoid

Confusing waiting time and turnaround time. Waiting time excludes the process's own burst; turnaround time (arrival to completion) includes it. Read which the question wants.
Calling a compiler "faster than an interpreter" without qualification. The compiled program runs faster; compilation itself is slower up front. Be precise about which you mean.
Blurring paging and segmentation. Paging uses fixed-size blocks (internal fragmentation); segmentation uses variable-size logical units (external fragmentation).
Saying lexical analysis "checks the grammar". It tokenises; syntax analysis checks the grammar. Assign each error type to the correct stage.
Treating inheritance and polymorphism as synonyms. Inheritance acquires members from a superclass; polymorphism is one interface behaving differently by object type.
Describing an OS function without a mechanism. "The OS manages memory" is thin; "the OS allocates memory to processes using paging and reclaims it when they terminate" earns the mark.
Forgetting that an interrupt saves state before servicing. The register contents (especially the PC) are pushed to a stack so the interrupted task can resume — omit this and the description is incomplete.

Mini-FAQ

Is an assembler a compiler? No. An assembler translates assembly language to machine code on a strict one-to-one basis; a compiler translates a high-level language, where one statement typically becomes many machine instructions. Keep the three translators distinct.

Why would anyone use an interpreter if compiled code runs faster? Interpreters make debugging easier (errors surface line by line as the program runs), give immediate execution without a separate build step, and offer portability across any machine with the interpreter. The trade-off is slower run-time execution and needing the interpreter present.

Is agile always better than waterfall? No — that is a common over-claim. Waterfall suits projects with stable, well-documented requirements and a fixed contract; agile suits evolving requirements with an engaged customer. The mark is for matching the method to the scenario, never for declaring one universally superior.

What is the difference between a real-time OS and a multi-tasking OS? A multi-tasking OS switches between processes to appear simultaneous but makes no timing guarantee; a real-time OS guarantees a response within a defined deadline, which is essential in control systems like the embedded devices in Processors & Hardware.

How does this module connect synoptically? Memory management builds on primary storage; the interrupt mechanism links to processor operation; the OOP paradigm and translator pipeline feed directly into Programming. Naming one such link in an extended answer signals the cross-topic understanding A-Level rewards.

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.

OCR A-Level Computer Science: Software & Systems — Complete Revision Guide

Guide Overview

System Software

Operating System Functions

Memory Management

Worked example: translating a logical address under paging

$\text{page number} = \left\lfloor \frac{5000}{1024} \right\rfloor = 4, \qquad \text{offset} = 5000 \bmod 1024 = 904$

The page table for this process maps logical page 4 to, say, physical frame 9. The physical address is then the frame's base plus the offset:

$(9 \times 1024) + 904 = 9216 + 904 = 10120$

Scheduling Algorithms

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

Worked example: FCFS versus SJF on the same processes

Process	Burst time
P1	8
P2	4
P3	9
P4	5

$\text{average waiting} = \frac{0 + 8 + 12 + 21}{4} = \frac{41}{4} = 10.25$

Shortest Job First reorders by burst time: P2 (4) → P4 (5) → P1 (8) → P3 (9). Completion times are 4, 9, 17 and 26, so waiting times are P2 = 0, P4 = 4, P1 = 9, P3 = 17:

$\text{average waiting} = \frac{0 + 4 + 9 + 17}{4} = \frac{30}{4} = 7.5$

Worked example: Round Robin and the quantum

Types of Programming Language

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

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

Intermediate code and virtual machines

Programming Methodologies

Object-Oriented Design

A short, concrete illustration ties the four principles together. Consider a base class and a subclass:

class Animal:
    def __init__(self, name):
        self.__name = name        # encapsulation: private attribute

    def get_name(self):           # controlled access via a getter
        return self.__name

    def speak(self):
        return "some sound"

class Dog(Animal):                # inheritance: Dog is-an Animal
    def speak(self):              # polymorphism: overrides speak()
        return "Woof"

Testing and Debugging

IDE Features

How to Revise Software & Systems

Exam Technique: Scoring the Software & Systems Questions

Common Mistakes to Avoid

Confusing waiting time and turnaround time. Waiting time excludes the process's own burst; turnaround time (arrival to completion) includes it. Read which the question wants.
Calling a compiler "faster than an interpreter" without qualification. The compiled program runs faster; compilation itself is slower up front. Be precise about which you mean.
Blurring paging and segmentation. Paging uses fixed-size blocks (internal fragmentation); segmentation uses variable-size logical units (external fragmentation).
Saying lexical analysis "checks the grammar". It tokenises; syntax analysis checks the grammar. Assign each error type to the correct stage.
Treating inheritance and polymorphism as synonyms. Inheritance acquires members from a superclass; polymorphism is one interface behaving differently by object type.
Describing an OS function without a mechanism. "The OS manages memory" is thin; "the OS allocates memory to processes using paging and reclaims it when they terminate" earns the mark.
Forgetting that an interrupt saves state before servicing. The register contents (especially the PC) are pushed to a stack so the interrupted task can resume — omit this and the description is incomplete.

OCR A-Level Computer Science: Software & Systems — Complete Revision Guide

Guide Overview

System Software

Operating System Functions

Memory Management

Worked example: translating a logical address under paging

Scheduling Algorithms

Worked example: FCFS versus SJF on the same processes

Worked example: Round Robin and the quantum

Types of Programming Language

Translators

Intermediate code and virtual machines

Programming Methodologies

Object-Oriented Design

Testing and Debugging

IDE Features

How to Revise Software & Systems

Exam Technique: Scoring the Software & Systems Questions

Common Mistakes to Avoid

Mini-FAQ

Related Reading

Stay in the loop

OCR A-Level Computer Science: Software & Systems — Complete Revision Guide

Guide Overview

System Software

Operating System Functions

Memory Management

Worked example: translating a logical address under paging

Scheduling Algorithms

Worked example: FCFS versus SJF on the same processes

Worked example: Round Robin and the quantum

Types of Programming Language

Translators

Intermediate code and virtual machines

Programming Methodologies

Object-Oriented Design

Testing and Debugging

IDE Features

How to Revise Software & Systems

Exam Technique: Scoring the Software & Systems Questions

Common Mistakes to Avoid

Mini-FAQ

Related Reading

Stay in the loop