2024 CCEA AS-Level Digital Technology 2650 Practice Paper with Answers

When commissioning a new system, an organisation must balance what the users actually need the system to do, how quickly the system must be delivered, and how much can be spent on developing it. These three factors — user needs, time and cost — are frequently in tension: for example, adding features to meet user needs can increase both time and cost. The answer is: user needs, time, cost.

1 mark each for any three of: user needs; time; cost (max 3). Accept 'budget' for cost and 'deadline' for time.

Flowcharts use a standard set of shapes so that algorithms can be read consistently by any programmer. A parallelogram represents an input or output operation, such as reading a score from the keyboard or displaying the average on screen. A rectangle represents a process, such as adding a score to a running total. A diamond (rhombus) represents a decision, such as checking whether all scores have been entered. The answer is: (i) parallelogram, (ii) rectangle, (iii) diamond/rhombus.

1 mark for parallelogram (input/output). 1 mark for rectangle (process). 1 mark for diamond/rhombus (decision). Accept alternative acceptable names; an oval is not accepted for decision.

A functional requirement describes something the system must do — a task or process it must carry out, such as letting staff book a member onto a class or recording a payment. A non-functional requirement describes a quality or constraint on how the system performs its functions, rather than a task itself, such as a required response time, level of availability, or security standard. For the gym booking system, functional requirements could include booking a member onto a class and recording payments, while non-functional requirements could include a maximum response time for bookings and a minimum level of system availability. The answer: 2 functional requirements (e.g. book a class, record payment) and 2 non-functional requirements (e.g. response time, availability).

1 mark each for two valid functional requirements specific to the gym scenario (max 2). 1 mark each for two valid non-functional requirements specific to the scenario (max 2). Reject requirements placed in the wrong category.

A thorough test plan uses more than one kind of test data to check that a program behaves correctly in every situation. Normal (valid) data lies safely within the accepted range, such as an age of 45, and checks that ordinary values are processed correctly. Extreme (boundary) data lies exactly on the limits of the accepted range, such as 0 or 120, and checks that the boundaries themselves are handled correctly. Erroneous (invalid) data lies outside the accepted range or is of the wrong type, such as -5 or the text 'abc', and checks that the program rejects data it should not accept. The answer: normal/valid, extreme/boundary, erroneous/invalid.

1 mark each for: normal/valid data; extreme/boundary data; erroneous/invalid data (max 3). Accept a suitable example in place of the term if the category is clearly implied.

RAD was designed to overcome the slow, rigid nature of the waterfall model. It relies heavily on building working prototypes early, which are shown to and refined with users, so the user is closely involved throughout development rather than mainly at the start. RAD also develops the system through a series of short iterative cycles, rather than in one long sequence of fixed stages, allowing requirements to be adjusted as understanding grows. The answer: prototyping, ongoing user involvement, iterative/short development cycles.

1 mark each for any three of: extensive use of prototyping; close/continuous user involvement; iterative/incremental cycles; faster delivery than waterfall (max 3, must be a genuine RAD feature, not a generic statement).

An algorithm is a precise, ordered sequence of steps for solving a problem or carrying out a task, independent of any particular programming language. Syntax is the set of grammatical rules that instructions in a specific language must follow for the program to be understood by the translator (e.g. correct punctuation and keyword use). A data type classifies the kind of value being stored or used, such as integer, real, character or Boolean, which determines what operations can be performed on it. A variable is a named location in memory whose stored value can change during the execution of a program, in contrast to a constant. The answer: (i) algorithm — ordered problem-solving steps; (ii) syntax — language's grammatical rules; (iii) data type — classification of the kind of value stored; (iv) variable — a named, changeable memory location.

1 mark for each correct definition: (i) algorithm; (ii) syntax; (iii) data type; (iv) variable (max 4). Accept any answer capturing the same meaning.

Every algorithm, however complex, can be built from three fundamental control structures. Sequence means instructions are carried out one after another in the order they are written. Selection means the program chooses between different paths depending on whether a condition is true or false (e.g. an IF statement). Iteration means a set of instructions is repeated, either a fixed number of times (count-controlled) or until/while a condition is met (condition-controlled). The answer: sequence, selection, iteration.

1 mark each for: sequence; selection; iteration (max 3). No credit for 'loop' alone without one of the required terms.

The three standard backup types are full backup, which copies every selected file regardless of whether it has changed; differential backup, which copies all files changed since the last full backup; and incremental backup, which copies only the files changed since the most recent backup of any type (full or incremental). The key difference between full and incremental backup is the amount of data copied and time taken: a full backup always copies everything and so takes the longest and uses the most storage, while an incremental backup copies only the most recent changes, so it is much faster and uses less storage, but restoring data requires the last full backup plus every incremental backup made since. The answer: full, differential, incremental backup; full backup copies all files every time, incremental backup copies only files changed since the last backup of any kind.

1 mark each for naming full, differential and incremental backup (max 3). 1 mark for a valid distinguishing point between full and incremental backup (e.g. amount of data copied, time taken, or storage used). Max 4.

A functional requirement specifies something the system must actually do — a process, task or piece of functionality that a user can directly interact with. Requirement 1 is functional because it describes a specific task the system must carry out: allowing a receptionist to book a child onto a swimming class. A non-functional requirement, by contrast, specifies a quality, standard or constraint that the system's functions must meet, rather than a task in itself. Requirement 2 is non-functional because it does not describe what the system does, but how well it must perform — specifically, its capacity to support 50 simultaneous users without a drop in performance. In general, functional requirements answer 'what must the system do?', while non-functional requirements answer 'how well, how fast, how securely, or under what constraints must it do it?'. The answer: requirement 1 is functional (a task); requirement 2 is non-functional (a performance constraint).

1 mark for a correct definition of functional requirement. 1 mark for a correct definition of non-functional requirement. 1 mark for correctly identifying requirement 1 as functional with justification. 1 mark for correctly identifying requirement 2 as non-functional with justification. 1 mark for an overall coherent contrast between the two (what vs how well). Max 5.

Storyboarding is used early in interface design to plan out, screen by screen, how a user will move through the system — typically as a series of annotated sketches or mock-ups showing the layout of each screen and the sequence in which they appear, without any working code behind them. This lets the design team and client agree on the overall structure and flow cheaply, before development begins. Prototyping goes a step further by producing an actual working (or partly working) version of the interface that real users can click through and interact with. Feedback from users trying the prototype is then used to refine the design before the full system is built, reducing the risk of expensive changes later. The answer: storyboarding — sketched screen sequence to plan layout/flow; prototyping — a working interactive model refined through user feedback.

1 mark for describing storyboarding as a sequence of screen sketches/mock-ups. 1 mark for its purpose (planning flow/layout before development). 1 mark for describing prototyping as a working/interactive model. 1 mark for its purpose (gathering user feedback to refine the design). Max 4.

Alpha testing is the first stage of user-style testing, carried out internally by the software company's own staff (who may not be part of the development team) in a controlled environment, aiming to find and fix obvious faults before the software goes anywhere near real customers. Beta testing follows alpha testing and releases a near-final version of the software to a limited number of real end users, who use it in their own real-world setting on their own hardware; this uncovers problems that only appear under genuine, varied conditions of use, such as unusual hardware combinations or unexpected user behaviour. A company benefits from using both because alpha testing is a cheap, controlled way to catch major internal faults early, while beta testing catches issues that internal testers, being close to the product, would not think to try, which reduces the risk of costly faults appearing after the full public release. The answer: alpha = in-house testing by staff before release; beta = testing by real users in real conditions after alpha; using both catches both internal technical faults and real-world usage problems before launch.

1 mark for a correct description of alpha testing (in-house/by staff). 1 mark for a correct description of beta testing (by real users/in real conditions). 1 mark for correctly sequencing them (beta follows alpha). 1 mark for a valid reason to use alpha (catches internal faults early/cheaply). 1 mark for a valid reason to use beta (catches real-world issues before full release). Max 5.

User documentation is written for the people who will actually operate the finished system in their day-to-day job, such as stock control staff or till operators; it explains, often with screenshots and step-by-step instructions, how to carry out tasks like adding a new stock item or generating a reorder report, and normally avoids technical jargon so that non-specialist staff can follow it easily. Technical documentation, by contrast, is written for IT professionals — programmers, systems analysts or maintenance staff — who will need to understand, fix or extend the system in future; it includes information such as the system design, program code with comments, data structures, file layouts and details of any algorithms used, and is written using precise technical language rather than being aimed at end users. The answer: user documentation (a how-to guide for end users, e.g. stock/till staff) versus technical documentation (a technical description of the system's inner workings for IT/programming staff who maintain it).

1 mark for a correct description of user documentation (contents). 1 mark for identifying its intended audience (end users/operational staff). 1 mark for a correct description of technical documentation (contents). 1 mark for identifying its intended audience (IT staff/programmers/maintainers). 1 mark for a clear overall contrast between the two purposes. Max 5.

When an organisation moves from an old system (which may be manual or a different computer system) to a new one, the existing data cannot simply be ignored — it must be converted, meaning it is extracted from the old system or source and transformed into a format that the new system can read and use correctly, for example changing a date field from text to a proper date data type, or restructuring records to match a new database design. A common problem during data conversion is that data held in the old format is incomplete, inconsistent, or simply incompatible with the structure required by the new system, so it must be cleaned or reformatted before it can be loaded, and if this is done carelessly, errors, duplicate records or lost data can result in the new system. The answer: data conversion is transforming existing data into a format the new system can use; a possible problem is incompatible/inconsistent data causing errors or data loss during transfer.

1 mark for describing data conversion as transferring/reformatting existing data for use in the new system. 1 mark for expanding on this (e.g. changing file/field format or structure). 1 mark for a valid problem that can occur (e.g. incompatible format, data loss, duplication, errors). 1 mark for development of that problem. Max 4.

An object is a single, specific instance of a class that exists while a program runs, holding its own values for the attributes defined by that class — for example, a 'Car' object called myCar with its own colour and speed. A class acts as a blueprint or template that defines what attributes (data) and methods (behaviours) any object created from it will have, without itself being a real, running instance. A method is a block of code, similar to a procedure or function, defined inside a class, which describes an action that objects of that class can perform, such as a 'brake()' method belonging to a Car class. Inheritance allows a new class (a subclass or child class) to be created from an existing class (a superclass or parent class), automatically taking on its attributes and methods, while also being able to add or override its own — for example, an 'ElectricCar' subclass inheriting from 'Car'. The answer: (i) object — a specific instance of a class; (ii) class — a template defining attributes/methods; (iii) method — a piece of code defining an object's behaviour; (iv) inheritance — a subclass automatically gaining the attributes/methods of a superclass.

1 mark for a correct explanation of each of: object; class; method; inheritance (1 mark each, max 4). 1 mark for a valid supporting example illustrating any one of the four terms. Max 5.

Effective project management for a software project relies on several key features. First, a project plan or schedule breaks the project into tasks and milestones with target deadlines, giving the team a clear timeline to work to and a way of tracking progress against it. Second, resource allocation assigns the people, budget and equipment needed to each task, ensuring the right staff with the right skills are working on the right part of the project at the right time, and that spending stays within budget. Third, risk management involves identifying, at the outset and throughout the project, factors that could delay or derail it (such as staff illness, a supplier failing to deliver, or requirements changing), and putting plans in place to reduce their likelihood or impact. Without these features, a software project is far more likely to run over time, over budget, or fail to deliver what was required. The answer: a project plan/schedule with milestones; allocation of resources (staff, budget, equipment); identification and management of risk.

1 mark for identifying and 1 mark for explaining each of three valid project management features (e.g. planning/scheduling, resource allocation, risk management, constraint management), max 2 marks per feature, overall max 5.

(a) Context (level 0) diagram — components:
1. External entity: Member.
2. Process 0: Book-Loan System (the whole system shown as a single process).
3. Data flows: 'loan request' from Member to Book-Loan System; 'overdue notice' from Book-Loan System to Member.
The context diagram deliberately shows no internal data stores or sub-processes — only the system as a single bubble and its external entities, to show the system's scope and boundary.

(b) Level 1 diagram — components:
1. External entity: Member.
2. Process 1: Check Member — receives 'member ID' from Member, reads/writes D1 Members.
3. Process 2: Check Book — receives 'book ID' from Member, reads/writes D2 Books.
4. Process 3: Record Loan — receives 'validated loan details' from Process 1 and Process 2, writes 'loan record' to D3 Loans.
5. Process 4: Issue Overdue Notice — reads D3 Loans, sends 'overdue notice' data flow to Member.
6. Data stores: D1 Members; D2 Books; D3 Loans.
7. Data flows, each labelled and shown as a one-way arrow: Member → Process 1 (member ID); Process 1 ↔ D1 (member details); Member → Process 2 (book ID); Process 2 ↔ D2 (book details); Process 1 → Process 3 and Process 2 → Process 3 (validated loan details); Process 3 → D3 (loan record); D3 → Process 4 (loan/due date data); Process 4 → Member (overdue notice).
The level 1 diagram expands the single context-diagram process into its main constituent processes and shows the data stores each one reads from or writes to, giving more detail about how the system works internally while still hiding the fine detail of each process's own logic. Final answer: context diagram = 1 process, 1 external entity, 2 data flows; level 1 diagram = 4 processes, 3 data stores, 1 external entity, with data flows as listed above.

Context diagram (3 marks): 1 mark for the system correctly shown as a single process; 1 mark for the external entity Member correctly identified; 1 mark for correctly labelled data flows in both directions (loan request in, overdue notice out). Level 1 diagram (5 marks): 1 mark for correctly decomposing the system into sensible processes (checking member, checking book, recording loan, issuing overdue notice — accept an equivalent valid decomposition); 1 mark for correctly identifying the three data stores (Members, Books, Loans); 1 mark for correctly connecting each process to the data store(s) it uses; 1 mark for correctly retaining the external entity Member with correct flows in/out; 1 mark for overall consistency with the context diagram (same external entity, same net flows in/out). Max 8.

(a) Since each task must follow directly after the one it depends on, and none overlap, the earliest start day of each task equals the earliest finish day of the task before it: A starts on day 0 and, lasting 4 days, finishes on day 4. B cannot start until A finishes, so it starts on day 4 and, lasting 6 days, finishes on day 10 (4+6=10). C cannot start until B finishes, so it starts on day 10 and, lasting 10 days, finishes on day 20 (10+10=20). D cannot start until C finishes, so it starts on day 20 and, lasting 5 days, finishes on day 25 (20+5=25).
(b) The total project duration is the finish day of the last task, D, which is 25 days. Checking by a second route: summing the four durations directly, since none of the tasks overlap, gives 4+6+10+5 = 25 days, which agrees with the finish day of task D.
(c) A Gantt chart displays each task as a horizontal bar plotted against a shared timeline, with the bar's length and position showing its duration and start/finish day directly. This makes it far easier to see at a glance how tasks relate to one another in time, whether any tasks overlap or run in parallel, and how the project is progressing against the plan — information that has to be worked out by calculation from a table of durations and dependencies alone. The answer: (a) A 0–4, B 4–10, C 10–20, D 20–25; (b) 25 days; (c) a Gantt chart gives an immediate visual picture of task timing/overlap that a table does not.

(a) 1 mark each for correct start/finish pairs for B, C and D consistent with A starting at day 0 (max 3); 1 further mark for full internal consistency across all four tasks. (b) 1 mark for 25 days, only if consistent with (a). (c) 1 mark for identifying a valid advantage (e.g. visual/timeline representation); 1 mark for developing why this helps (e.g. shows overlap, progress, duration at a glance); 1 mark for a specific comparison to the table format. Max 8 total.

Indicative content:
• Interviews: one-to-one discussion with staff (e.g. receptionist, dentist) allows the analyst to ask follow-up questions and explore issues in depth, and can build rapport, but is time-consuming to conduct and analyse, and answers may be biased by what the interviewee thinks the analyst wants to hear.
• Questionnaires: can be distributed to many staff/patients quickly and cheaply, giving a broad range of views and easily quantifiable/analysable closed-question data, but response rates can be low and there is no opportunity to clarify or follow up an ambiguous answer.
• Observation: watching staff actually carry out the current booking process shows what really happens (rather than what staff say happens), revealing informal workarounds, but staff may work differently/more carefully when they know they are being watched (the 'Hawthorne effect'), and it does not reveal staff's opinions or reasons.
• Document sampling: examining existing appointment books, cancellation forms or letters shows the exact data currently recorded and its format, which is useful for designing data capture forms and files, but documents may be out of date or not reveal the full informal process actually followed.
• Evaluation: for this scenario, a combination is likely to be most effective — observation and document sampling to establish the current, real process and data formats accurately, followed by interviews with key staff (e.g. the practice manager) to explore requirements in depth, with a short questionnaire to patients to gauge their views on the current booking experience efficiently; relying on a single technique risks missing either the factual detail (from interviews alone) or the reasoning behind current practice (from observation/documents alone).
Final answer: no single technique is sufficient — an evaluated combination (e.g. observation and document sampling for accuracy, interviews for depth, questionnaires for breadth) best suits investigating this dental booking system.

Band 2 [5–6 marks]: detailed, accurate description of at least three fact-finding techniques covering genuine strengths and weaknesses, clear evaluative justification of which technique(s) suit this scenario with appropriate digital technology terminology, high standard of QWC.
Band 1 [3–4 marks]: competent description of two or more techniques, one-sided or limited evaluation, basic terminology, clear presentation.
Band 0 [1–2 marks]: partial description of one or two techniques lacking detail, minimal terminology, unclear presentation.
0 marks: no creditworthy content.

Indicative content:
• From the development team's point of view: prototyping lets designers build a quick, working (or partly working) version of the app's screens early, so problems with the layout, navigation or workflow can be found and fixed before full development, saving time and cost compared to discovering the same problems after the app is fully coded; showing a prototype to stakeholders also helps clarify requirements that were vague or misunderstood at the analysis stage.
• From the customer's point of view: involving real or representative customers in testing the prototype means the finished interface is more likely to be intuitive, accessible and to actually meet their needs (e.g. clear navigation for checking a balance or making a transfer), which increases the chance customers will trust and adopt the app; however, customers involved early may form expectations from the prototype that are not fully met in the final release if the prototype's look/feel changes.
• Costs/risks: building and repeatedly revising prototypes takes designer time and can add to the overall project timescale if changes are frequent or poorly managed; there is also a risk, particularly with a highly polished prototype, that stakeholders assume the system is nearer to completion than it really is.
• Evaluation: for a banking app, where trust, security perception and ease of use are critical to customer adoption, the benefit of catching usability problems early and building customer confidence through their involvement is likely to outweigh the extra time and cost of the prototyping process, provided the number of prototype iterations is controlled.
Final answer: prototyping benefits both the development team (cheaper, earlier fixing of design/usability problems, clarified requirements) and customers (a more usable, trusted final interface), and for a banking app these benefits are judged to outweigh the added time/cost of the iterative process.

Band 2 [5–6 marks]: detailed, accurate description of prototyping's benefits and drawbacks from both the development team's and customers' perspectives, clear evaluative judgement with appropriate digital technology terminology, high standard of QWC.
Band 1 [3–4 marks]: competent description covering one perspective well or both perspectives with limited detail, some evaluation, basic terminology, clear presentation.
Band 0 [1–2 marks]: partial description lacking detail or addressing only one point, minimal terminology, unclear presentation.
0 marks: no creditworthy content.

Indicative content:
• Direct changeover: the old system is stopped and the new system started immediately. Cheapest and fastest method, but if the new system fails there is no working system (paper or otherwise) to fall back on, which is extremely risky for a hospital's patient records.
• Parallel changeover: the old and new systems run alongside each other for a period, with results cross-checked. Very safe, as the old (paper) system remains available if the new system has faults, but it is expensive and slow, as staff must maintain both systems (double the workload) for the overlap period.
• Pilot changeover: the new system is introduced in one part of the organisation first (e.g. one ward or department) before being rolled out elsewhere. Limits the impact of any problems to a small area and allows lessons to be learned before wider rollout, but the pilot area may not be representative of the whole hospital, and rollout still takes time.
• Phased changeover: the new system is introduced gradually, module by module or function by function (e.g. appointments first, then records, then billing), across the whole hospital at once. Limits risk at any one time to a single module and allows staff to be trained and adjust gradually, but the overall changeover still takes a long time, and running some old and some new modules together for a time can be complex to manage.
• Evaluation: given the safety-critical nature of patient records and the serious consequences of data loss or system failure in a hospital, direct changeover is too risky despite its low cost and speed; a combination of pilot changeover (to test the system safely on one ward first) followed by phased changeover across the rest of the hospital is likely to give the best balance of risk management and practical rollout time, even though parallel running for the pilot ward would add an extra layer of safety at some additional cost.
Final answer: for a hospital's patient records, direct changeover is too risky; pilot changeover (to test safely on a limited scale) followed by phased rollout is evaluated as the best balance of safety, cost and time, with parallel running considered for extra safety during the pilot stage.

Band 2 [5–6 marks]: detailed, accurate description of all four changeover methods with genuine advantages/disadvantages, clear evaluative justification of a recommended approach for this hospital scenario with appropriate digital technology terminology, high standard of QWC.
Band 1 [3–4 marks]: competent description of at least two methods, one-sided or limited evaluation, basic terminology, clear presentation.
Band 0 [1–2 marks]: partial description of one or two methods lacking detail, minimal terminology, unclear presentation.
0 marks: no creditworthy content.

Indicative content:
• Waterfall model: development proceeds through fixed, sequential stages (e.g. analysis, design, development, testing, implementation), each completed before the next begins. This gives a clear, predictable structure with well-defined documentation at each stage, which suits projects where requirements are stable and well understood from the outset, but it makes late changes to requirements difficult and expensive, and the client does not see a working system until very late in the project.
• Agile approach: development proceeds through short, repeated cycles (sprints), each producing a small working increment of the system that is reviewed with the client, allowing requirements to evolve as understanding improves. This suits projects where requirements are likely to change or are not fully understood at the start, and gives the client early, regular sight of working software, but it can be harder to fix an overall project cost/timescale in advance, and requires close, continuous client involvement throughout.
• Evaluation for this scenario: a stock-control system typically has some well-established core requirements (e.g. recording stock in/out, generating reorder reports) but clients often refine finer details (e.g. exact report layouts, extra features) once they see the system working, which favours Agile's ability to adapt; however, if the client has given the software house a fixed, well-specified set of requirements and a fixed budget/deadline, the predictability of the waterfall model's documentation and stage sign-off may be more appropriate and easier to contract for.
Final answer: Agile is judged better suited where the client's requirements are likely to evolve and early working software is valued, while waterfall suits a scenario with fixed, well-understood requirements and a need for predictable, staged documentation and cost/time control; for a typical stock-control project with some requirement uncertainty, Agile is the more appropriate overall recommendation.

Band 2 [5–6 marks]: detailed, accurate description of both the waterfall model and Agile with genuine advantages/disadvantages, clear evaluative judgement/recommendation for this scenario with appropriate digital technology terminology, high standard of QWC.
Band 1 [3–4 marks]: competent description of both approaches with limited development, some evaluation, basic terminology, clear presentation.
Band 0 [1–2 marks]: partial/one-sided description lacking detail, minimal terminology, unclear presentation.
0 marks: no creditworthy content.

A bit (binary digit) is the smallest unit of data a computer can store, holding either a 0 or a 1. A byte is a group of 8 bits, commonly used as the basic unit for storing a single character. A kilobyte (KB) is 1024 bytes, i.e. \( 2^{10} \) bytes, since computer storage is measured in powers of two. The answer: (i) a single binary digit (0 or 1); (ii) 8 bits; (iii) 1024 bytes.

1 mark for each correct definition: (i) bit; (ii) byte; (iii) kilobyte. Max 3. 1000 bytes is not accepted as the definition of a kilobyte at this level — require 1024.

ASCII (American Standard Code for Information Interchange) is a character-encoding standard that assigns each of a limited set of characters — the basic Latin letters (upper and lower case), digits 0–9, punctuation and some control codes — a unique binary code, traditionally using 7 or 8 bits, giving at most 256 possible characters. Unicode is a more extensive character-encoding standard that uses more bits per character, allowing it to represent a vastly larger number of characters than ASCII, including the letters and symbols of many of the world's languages (e.g. Chinese, Arabic, Cyrillic) as well as symbols such as emoji. Unicode is needed in addition to ASCII because ASCII's limited set of codes simply cannot represent characters outside the basic Latin alphabet, so any system that needs to store or display text in other languages/scripts requires Unicode. The answer: (i) ASCII — a coding system for basic Latin characters using 7/8-bit codes; (ii) Unicode — a coding system able to represent many more characters/languages; Unicode is needed because ASCII cannot represent non-Latin characters.

1 mark for a correct description of ASCII. 1 mark for a correct description of Unicode. 1 mark for a valid reason Unicode is needed (e.g. represents international/non-Latin characters that ASCII cannot). Max 3.

Data consists of raw facts and figures with no context or meaning attached, such as the number 37 on its own. Information is produced when data is processed, organised or given context so that it becomes meaningful, such as recognising that '37' is a patient's body temperature in degrees Celsius. Knowledge goes a step further: it is the understanding a person builds up from information, often combined with experience, that allows them to interpret it and act on it appropriately — for example, a nurse's knowledge that a temperature of 37°C is within the normal range, whereas 40°C indicates a fever requiring treatment. The answer: data (raw fact, e.g. 37) leads to information (data in context, e.g. body temperature 37°C) leads to knowledge (understanding to act on it, e.g. recognising 37°C is normal but 40°C is a fever).

1 mark for a correct description of data with an example. 1 mark for a correct description of information with an example, showing progression from the data example. 1 mark for a correct description of knowledge with an example, showing progression from the information example. Max 3.

A range check tests whether an entered value falls between a sensible minimum and maximum, and is well suited to a date-of-birth field, since it could check that the date entered is not later than today's date (a person cannot be born in the future) and not earlier than a set minimum (e.g. more than 120 years ago), catching obviously mistyped dates. A format check would also be valid, checking that the date has been entered in the required pattern, such as DD/MM/YYYY. The answer: a range check — confirms the date lies between an acceptable earliest and latest date (e.g. not in the future and not more than roughly 120 years ago).

1 mark for naming a valid check (e.g. range check, format check, presence check, type check). 1 mark for correctly explaining what that specific check tests for in this context. Max 2.

The processor (CPU) is the component that fetches, decodes and executes program instructions, carrying out the actual processing in the computer. Main memory (RAM) temporarily stores the programs and data that are currently in use, allowing the processor fast access to them while the computer is switched on. Buses are sets of parallel wires that carry data, memory addresses and control signals between the processor and other components, such as memory and input/output controllers, allowing them to communicate. The answer: processor (executes instructions), main memory (temporarily holds current programs/data), buses (carry data/address/control signals between components). Other acceptable components include cache memory, registers, clock, and I/O controllers.

1 mark for each correctly named internal component with a correct statement of its role (any three of: processor, main memory, cache memory, clock, buses, I/O controllers, registers, ports). Max 3.

A smartphone screen displaying tappable icons is a WIMP-style interface (windows, icons, menu, pointer), even though on a touchscreen the finger takes the place of a mouse pointer. A technician typing text commands directly to a server is using a command line interface, where the user must type precise instructions in the correct syntax rather than selecting options visually. An online form with labelled boxes for entering specific pieces of information, such as name and address, is a forms dialogue interface, which guides the user to enter data into a structured layout. The answer: (i) WIMP, (ii) command line, (iii) forms dialogue.

1 mark each for correctly identifying: (i) WIMP; (ii) command line; (iii) forms dialogue. Max 3.

Data compression reduces the size of a file, which means it takes up less storage space on a device and can be transmitted over a network or downloaded much more quickly — important for large media files such as images and audio. For a photograph, JPEG is a widely used compressed image format. For a short sound recording, MPEG (of which MP3 is a well-known example) is a suitable compressed audio format. The answer: compression reduces file size for storage/transfer speed; (i) JPEG for a photograph; (ii) MPEG (e.g. MP3) for a sound recording.

1 mark for a correct reason for data compression (reduces file size, so less storage used and/or faster transfer). 1 mark for a valid compressed image format (e.g. JPEG, GIF). 1 mark for a valid compressed audio format (e.g. MPEG/MP3). Max 3.

Because several different programs are apparently running at the same time on the same computer by having the processor's attention switched rapidly between them, this describes a multitasking operating system. A multitasking operating system gives each running program a small slice of processor time in turn, switching between them so quickly that, from the user's point of view, all the programs appear to be running simultaneously, even though at any one instant the processor is really only executing one of them. The answer: multitasking operating system — the OS rapidly switches the processor between multiple running programs so they appear to run concurrently.

1 mark for correctly identifying 'multitasking' operating system. 2 marks for a correct explanation of what multitasking means (1 mark for rapid switching between programs; 1 mark for programs appearing to run simultaneously/concurrently to the user). Max 3.

A URL, or Uniform Resource Locator, is the address used to locate a specific resource, such as a web page, on the internet. HTTP, or Hypertext Transfer Protocol, is the set of rules used to transfer web pages and other resources between a web server and a web browser. An ISP, or Internet Service Provider, is a company that provides individuals and organisations with access to the internet. The answer: (i) Uniform Resource Locator; (ii) Hypertext Transfer Protocol; (iii) Internet Service Provider.

1 mark each for correctly stating: (i) Uniform Resource Locator; (ii) Hypertext Transfer Protocol; (iii) Internet Service Provider. Max 3.

(a) To convert 91 to 8-bit binary, repeatedly subtract the largest possible power of two: 91 - 64 = 27, so bit 64 = 1; 27 - 32 is not possible, so bit 32 = 0; 27 - 16 = 11, so bit 16 = 1; 11 - 8 = 3, so bit 8 = 1; 3 - 4 is not possible, so bit 4 = 0; 3 - 2 = 1, so bit 2 = 1; 1 - 1 = 0, so bit 1 = 1. This gives \( 91 = 01011011_2 \). Check: \( 64+16+8+2+1 = 91 \). This confirms the conversion.
(b) To represent -91 in 8-bit two's complement, first write +91 in binary (from part (a)): 01011011. Invert every bit: 10100100. Add 1 to the result: 10100100 + 1 = 10100101. Check by a second route: in two's complement, an 8-bit pattern represents \( -128b_7 + 64b_6+32b_5+16b_4+8b_3+4b_2+2b_1+b_0 \). For 10100101: \( -128 + 32 + 4 + 1 = -91 \). This confirms the answer. Final answer: (a) 91 = 01011011; (b) -91 = 10100101 (in 8-bit two's complement).

(a) 1 mark for correct working/method shown; 1 mark for the correct answer 01011011. (b) 1 mark for correctly writing +91 in binary; 1 mark for correctly inverting the bits; 1 mark for correctly adding 1 to give the final answer 10100101. Max 5. Accept the answer alone with correct working shown even if presented via a different valid method (e.g. the direct two's complement algorithm).

Multiply each digit by its weight (left to right: weights 7, 6, 5, 4, 3, 2):
3×7 = 21
7×6 = 42
2×5 = 10
9×4 = 36
5×3 = 15
8×2 = 16
Sum = 21+42+10+36+15+16 = 140.
Divide by 11: \( 140 \div 11 \) = 12 remainder 8, since \( 12 \times 11 = 132 \) and \( 140-132=8 \).
Check digit = 11 - remainder = 11 - 8 = 3.
Check by a second route (pairing each digit with the same weight in the opposite listing order — rightmost digit 8 with weight 2, then 5 with weight 3, 9 with weight 4, 2 with weight 5, 7 with weight 6, 3 with weight 7): 8×2=16, 5×3=15, 9×4=36, 2×5=10, 7×6=42, 3×7=21; sum = 16+15+36+10+42+21 = 140 — the same total, since this simply re-orders the same digit/weight pairs, confirming the sum of 140 and check digit of 3.
Final answer: the Modulus-11 check digit for 372958 is 3, giving the full code 3729583.

1 mark for correctly multiplying each digit by its correct weight. 1 mark for the correct sum of products (140). 1 mark for correctly dividing by 11 and finding the remainder (8). 1 mark for correctly subtracting the remainder from 11. 1 mark for the correct final check digit (3). Max 5. Award full marks for the correct answer of 3 with working shown; allow follow-through credit for a correct method with one arithmetic slip, provided the final check digit remains in the valid 0–9/X range.

Total number of pixels = \( 1200 \times 800 = 960{,}000 \) pixels.
Each pixel uses 24 bits = \( 24 \div 8 = 3 \) bytes.
Total file size in bytes = \( 960{,}000 \times 3 = 2{,}880{,}000 \) bytes.
Convert to kilobytes: \( 2{,}880{,}000 \div 1024 = 2812.5 \) KB.
Convert to megabytes: \( 2812.5 \div 1024 = 2.7466\ldots \) MB, which rounds to 2.75 MB (2 d.p.).
Check by a second route: convert directly using \( 1 \text{ MB} = 1024 \times 1024 = 1{,}048{,}576 \) bytes, so \( 2{,}880{,}000 \div 1{,}048{,}576 = 2.7466\ldots \) MB, which again rounds to 2.75 MB — the same result, confirming the answer.
Final answer: the uncompressed file size is 2.75 MB.

1 mark for calculating the total number of pixels (960,000). 1 mark for correctly converting 24 bits to 3 bytes per pixel. 1 mark for the correct total in bytes (2,880,000). 1 mark for correct conversion to KB (2812.5 KB). 1 mark for the correct final answer in MB to 2 d.p. (2.75 MB), with correct working. Max 5. Accept full credit for an equivalent direct calculation using 1 MB = 1,048,576 bytes.

The fetch-execute cycle is the basic sequence of steps the processor repeats continuously to run a program. During the fetch stage, the address of the next instruction (held in a register such as the program counter) is placed on the address bus, and the instruction stored at that memory address is copied along the data bus into the processor's instruction register; the program counter is then updated to point to the next instruction. During the decode stage, the control unit interprets the fetched instruction to determine what operation it represents and what data or addresses it needs. During the execute stage, the processor actually carries out the instruction, for example performing a calculation in the arithmetic and logic unit (ALU) or storing a result back in memory. Once execution is complete, the cycle repeats with the next fetch, and this happens continuously, many millions of times per second, for as long as the processor runs. The answer: fetch (retrieve the next instruction from memory), decode (interpret what the instruction means), execute (carry out the instruction) — then repeat.

1 mark for describing the fetch stage (retrieving the instruction from memory, e.g. via the address/data bus and program counter). 1 mark for describing the decode stage (interpreting the instruction). 1 mark for describing the execute stage (carrying out the instruction). 1 mark for correctly stating the cycle repeats continuously. 1 mark for correct use of relevant terminology (e.g. program counter, ALU, registers, buses). Max 5.

Clock speed is the rate, measured in gigahertz (GHz), at which the processor's internal clock generates pulses that synchronise its operations; a higher clock speed means more fetch-execute cycles, and therefore more instructions, can potentially be carried out every second, generally making processing faster. Processor type/architecture also affects speed: processors differ in factors such as the number of cores (allowing more instructions to be processed in parallel), the amount of cache memory (fast memory close to the processor that reduces the time spent waiting for data from slower main memory), and the efficiency of their instruction set, so two processors running at the same clock speed can still complete the same amount of work at different real-world speeds. The answer: clock speed (a higher clock speed allows more cycles/instructions per second) and processor type (differences in cores, cache and architecture affect how much work is done per cycle).

1 mark for identifying clock speed as a factor. 1 mark for explaining why (more cycles/instructions per second at a higher clock speed). 1 mark for identifying processor type as a factor. 1 mark for explaining why (differences in cores/cache/architecture affect work done per cycle). 1 mark for a coherent overall link between the two factors and overall processing speed. Max 5.

Secondary storage is needed because main memory (RAM) is volatile, meaning its contents are lost as soon as the computer is switched off, and because RAM is relatively limited in capacity and expensive per unit of storage compared with secondary storage; secondary storage devices retain data permanently (non-volatile) without power, and can typically hold far more data at a lower cost per gigabyte, so they are used to store the operating system, applications and user files between sessions. A magnetic storage example is a hard disk drive (HDD), which stores data as areas of magnetisation on spinning magnetic platters. An optical storage example is a DVD or Blu-ray disc, which stores data as microscopic pits and lands read by a laser. A flash storage example is a USB flash drive or solid-state drive (SSD), which stores data electronically in flash memory chips with no moving parts. The answer: secondary storage is needed because RAM is volatile and limited in capacity; examples — magnetic: HDD; optical: DVD/Blu-ray; flash: USB flash drive/SSD.

1 mark for a correct reason secondary storage is needed (RAM is volatile). 1 mark for a further correct reason (RAM is limited in size/expensive per unit). 1 mark for a valid magnetic storage example. 1 mark for a valid optical storage example. 1 mark for a valid flash storage example. Max 5.

Data validation is carried out automatically by a computer program at the point of data entry to check that data is sensible and reasonable — for example, that it falls within an expected range, is of the correct type, or matches a required format — and rejects data that fails these checks. Data verification, by contrast, checks that data has actually been entered, copied or transferred correctly, typically by comparing it against the original source; common verification methods include double entry (the same data is entered twice, independently, and the two entries compared for a mismatch) and proofreading (visually comparing entered data against the original document). The key limitation of data validation is that it can only check whether data is plausible, not whether it is actually correct: a value can be entirely valid in range, type and format and still be wrong. For example, if a person's real age is 25 but 52 is mistakenly entered, this would still pass a range check (as 52 is a sensible age), so the error would go undetected by validation alone; only verification, or independent checking against the true source, would catch this kind of transcription error. The answer: validation checks that data is reasonable/sensible (automatically, at entry); verification checks that data was entered/copied correctly (e.g. double entry, proofreading); validation alone cannot guarantee accuracy because an incorrect value can still be a plausible, valid one (e.g. a mistyped but still sensible number).

1 mark for a correct description of data validation. 1 mark for a correct description of data verification, including a named method (double entry or proofreading). 1 mark for correctly identifying that validation cannot guarantee accuracy. 1 mark for a valid, specific example illustrating why (a wrong-but-plausible value passing validation). 1 mark for a clear, coherent overall explanation linking validation, verification and the limitation together. Max 5.

Zipping compresses one or more files by applying a compression algorithm that reduces the amount of data needed to represent the file's content — for example, by identifying repeated patterns or sequences within the data and replacing them with a shorter code that can later be used to reconstruct the original file exactly (lossless compression), often bundling several files together into a single compressed archive (a 'zip' file) in the process. An advantage of compressing files before emailing them is that the resulting smaller file size means the attachment uploads and downloads more quickly, and takes up less of the sender's and recipient's storage and email quota, which is especially useful for attachments that would otherwise be close to an email system's size limit. A disadvantage is that the recipient must decompress (unzip) the file before they can open and use its contents, which is an extra step that could confuse a less experienced user, and the process of compressing and decompressing files takes some extra processing time. The answer: zipping compresses data by encoding it more efficiently (e.g. removing redundancy) so it takes up less space; advantage — faster transfer and less storage/email space used; disadvantage — the recipient must unzip the file before use, and compression/decompression takes extra time.

1 mark for a correct description of what zipping does (reduces file size by encoding data more efficiently/removing redundancy). 1 mark for further detail (e.g. can bundle multiple files into one archive, or is reversible/lossless). 1 mark for a valid advantage of compressing email attachments. 1 mark for a valid disadvantage. 1 mark for overall clarity/coherence of the explanation. Max 5.

Domain names are organised as a hierarchy, structured so that the most general part of the name is on the right and the most specific part is on the left. At the top of the hierarchy is the top-level domain (TLD), such as .com (commercial), .org (organisation) or .uk (United Kingdom), which broadly categorises the domain. Below this sits the second-level domain, typically the specific name an organisation registers, such as 'ccea' in 'ccea.org.uk'; further sub-domains (e.g. 'www') can be added in front of this for particular services or sections of a site. This hierarchical structure, managed through domain name registries, ensures every domain name is unique and can be resolved, via the Domain Name System (DNS), to the correct web server's IP address. The World Wide Web Consortium (W3C) is the international organisation responsible for developing and agreeing open standards for web technologies, such as HTML and CSS, so that web pages are built to a common specification; this means pages designed to these standards should display and behave consistently across different web browsers, devices and operating systems, rather than each browser interpreting web content differently. The answer: domain names are organised hierarchically (top-level domain, then second-level domain, then optional sub-domains, read right to left); the W3C agrees open web standards (e.g. HTML/CSS) so that web content works consistently across browsers/devices.

1 mark for correctly describing the hierarchical structure of domain names. 1 mark for a correct example illustrating a top-level domain. 1 mark for a correct example illustrating a second-level domain/sub-domain. 1 mark for correctly describing the W3C's role (developing/agreeing web standards). 1 mark for explaining why this matters (consistency across browsers/devices). Max 5.

Cascading style sheets (CSS) are used to control how a web page's HTML content is presented — including aspects such as colours, fonts, spacing and page layout — separately from the HTML that defines the page's structure and content; a single CSS file can be linked to many HTML pages, meaning that the visual style of an entire website can be defined once and then updated consistently across every page simply by editing that one style sheet, rather than having to change the formatting of each page individually. Client-side processing is carried out on the user's own device, by their web browser — for example, JavaScript code that validates a form or updates part of a page without reloading it runs on the user's computer, using the user's own processing power. Server-side processing, in contrast, is carried out on the remote web server before the resulting web page is even sent to the user — for example, a server-side script might retrieve data from a database and build a personalised page, which is then sent to the user's browser as a finished HTML page. The answer: CSS controls a web page's presentation/styling separately from its HTML content, allowing consistent styling across many pages from one style sheet; client-side processing happens in the user's own browser/device, while server-side processing happens on the web server before the page is delivered.

1 mark for correctly describing what CSS controls (presentation/styling, separate from HTML content). 1 mark for the benefit of using CSS (consistent styling across multiple pages from one style sheet). 1 mark for a correct description of client-side processing (carried out in the user's browser/device). 1 mark for a correct description of server-side processing (carried out on the web server before delivery). 1 mark for a valid example illustrating the client-side/server-side distinction. Max 5.

Indicative content:
• Magnetic (e.g. hard disk drive/magnetic tape): very large storage capacity at relatively low cost per gigabyte, and can be rewritten many times, making it well suited to large nightly backups; however, magnetic media (especially tape) can be slower to access data from, and has moving parts (in HDDs) that are vulnerable to physical shock/mechanical failure.
• Optical (e.g. DVD/Blu-ray): cheap and durable for long-term archival storage, and read-only versions resist accidental overwriting; but capacity is much smaller than magnetic or flash media (a single disc is far too small for most business backups), so many discs would be needed and this is impractical to manage/automate for a nightly backup.
• Flash (e.g. SSD/flash drive): very fast read/write speeds and no moving parts, so more reliable against physical shock/vibration than magnetic HDDs, and increasingly offers large capacities; however, flash storage is generally more expensive per gigabyte than magnetic storage, and flash memory cells wear out after a very large number of write cycles, which matters for something rewritten every night.
• Evaluation: for a nightly backup of critical business data, the very large capacity, low cost per gigabyte and rewritability of magnetic storage (e.g. an HDD-based backup system or tape) makes it the most practical main choice, given that nightly backups involve large and frequently repeated writes; flash storage could be used where backup speed is critical and budget allows, while optical storage is best reserved for occasional long-term archival copies rather than the everyday nightly backup itself.
Final answer: magnetic storage is evaluated as the most suitable everyday choice for nightly backups, due to its large capacity, low cost and rewritability, with flash considered for speed-critical needs and optical kept for long-term archival copies only.

Band 2 [5–6 marks]: detailed, accurate description of the benefits and drawbacks of all three media types specifically applied to the backup scenario, clear evaluative recommendation with appropriate digital technology terminology, high standard of QWC.
Band 1 [3–4 marks]: competent description of at least two media types, some evaluation, basic terminology, clear presentation.
Band 0 [1–2 marks]: partial description of one or two media types lacking detail, minimal terminology, unclear presentation.
0 marks: no creditworthy content.

Indicative content:
• WIMP (windows, icons, menu, pointer): highly visual and intuitive, as users select options by pointing/tapping on recognisable icons and menus rather than remembering commands, which suits inexperienced users well; however, a WIMP interface with too many windows, icons or menu options can overwhelm a first-time user if not carefully simplified for a kiosk.
• Command line: requires the user to know and type exact, correctly spelled commands and syntax, offering no visual prompts to guide an unfamiliar user, so it would be extremely difficult and frustrating for an inexperienced member of the public and is not appropriate for this kiosk.
• Forms dialogue: guides the user step by step through labelled boxes/fields to enter specific information, which can be made very simple and structured (e.g. clear on-screen instructions, one task at a time), making it easy to follow even for a first-time user, though it can feel slow or rigid if a user wants to do something the fixed form structure does not anticipate.
• Evaluation: for a public kiosk aimed at inexperienced users, command line is entirely unsuitable, as it demands knowledge the target users will not have; a carefully simplified WIMP interface (e.g. a small number of large, clearly labelled icons/buttons) combined with forms dialogue elements to guide data entry (e.g. entering a reference number) is likely to be the most usable overall solution, since it minimises the need for the user to recall anything and instead lets them recognise and select what they need.
Final answer: command line is unsuitable for inexperienced kiosk users; a simplified WIMP interface, supported by forms dialogue for structured data entry, is evaluated as the most appropriate design for this scenario.

Band 2 [5–6 marks]: detailed, accurate description of all three interface types with genuine advantages/disadvantages specifically applied to an inexperienced public user, clear evaluative recommendation with appropriate digital technology terminology, high standard of QWC.
Band 1 [3–4 marks]: competent description of at least two interface types, some evaluation, basic terminology, clear presentation.
Band 0 [1–2 marks]: partial description of one or two interface types lacking detail, minimal terminology, unclear presentation.
0 marks: no creditworthy content.

Indicative content:
• Proprietary software: usually has a purchase or licence cost, but typically comes with dedicated technical support, regular official updates, and is widely used, meaning it is easy to find trained staff/volunteers who already know how to use it and easy to share files with other organisations using the same standard formats; the ongoing licence cost, however, may be a significant burden for a charity with a limited budget, and the source code cannot be inspected or modified.
• Open source software: generally free to obtain and use, which directly reduces costs for a charity, and its source code can be freely viewed, modified and redistributed, allowing technically able users to adapt it to specific needs; however, official technical support may be limited or rely on community forums rather than a dedicated helpline, and some staff/volunteers may be less familiar with it, requiring some retraining, and file format compatibility with organisations using proprietary software can occasionally cause minor issues.
• Evaluation: for a small charity, which is likely to have a constrained budget and limited dedicated IT support, the low/zero cost of open source software is a significant advantage, and provided a reasonably popular open-source package is chosen (with an active community and broad file-format compatibility), the reduced formal support can be substituted with online community help; however, if the charity's staff/volunteers are already experienced with a specific proprietary package and frequently need seamless compatibility with partner organisations, the retraining time and any compatibility issues of switching could outweigh the cost savings.
Final answer: for a budget-constrained charity, open source software is evaluated as the generally more appropriate choice on cost grounds, provided a well-supported package is selected, though proprietary software remains preferable where existing staff familiarity or guaranteed compatibility/support matter more than cost.

Band 2 [5–6 marks]: detailed, accurate description of the benefits and drawbacks of both proprietary and open source software specifically applied to the charity scenario, clear evaluative recommendation with appropriate digital technology terminology, high standard of QWC.
Band 1 [3–4 marks]: competent description of both types with limited development, some evaluation, basic terminology, clear presentation.
Band 0 [1–2 marks]: partial/one-sided description lacking detail, minimal terminology, unclear presentation.
0 marks: no creditworthy content.

Indicative content:
• Encryption: scrambles data (such as a customer's card details) using a key so that it is unreadable if intercepted; public/private key (asymmetric) encryption allows the retailer to publish a public key that any customer's browser can use to encrypt data, while only the retailer's private key can decrypt it, which is effective for securing data sent to the retailer without needing to share a secret key in advance, though encryption/decryption adds some processing overhead.
• HTTPS (Hypertext Transfer Protocol Secure): the secure version of HTTP, which encrypts the data exchanged between the customer's browser and the retailer's web server, protecting it from being read if intercepted in transit; it is now the expected standard for any page handling payment details, and its absence would likely make customers distrust the site, but HTTPS alone does not guarantee the retailer's server itself is otherwise secure.
• SSL (Secure Sockets Layer, and its modern successor TLS): the underlying protocol that actually establishes the encrypted connection used by HTTPS, negotiating encryption keys between browser and server at the start of a session; essential to making HTTPS work, though older/outdated versions of SSL have known vulnerabilities, so the retailer must keep this updated.
• Digital certificate/digital signature: a certificate issued by a trusted certificate authority verifies that the retailer's website is genuinely who it claims to be, preventing a customer's browser from being tricked into trusting a fake copycat site; a digital signature can similarly confirm that data has not been tampered with in transit; without this, encryption alone would not stop a customer being deceived into sending details to an impostor site.
• Evaluation: no single method alone is sufficient — genuine end-to-end security for this online payment scenario needs all of these working together: a valid digital certificate from a recognised authority to prove the retailer's identity, SSL/TLS to establish the secure connection, HTTPS to carry the encrypted traffic, and strong (e.g. public/private key) encryption to protect the actual data, so the retailer should use the full combination rather than relying on any one measure in isolation.
Final answer: encryption, HTTPS, SSL/TLS and a digital certificate each protect a different aspect of the transaction (data content, transport, connection security and site identity respectively); the retailer should use all of them together, rather than any single method alone, to properly secure customer payment details.

Band 2 [5–6 marks]: detailed, accurate description of encryption, HTTPS, SSL and digital certificates with a clear evaluative judgement that a combination of measures is needed for this scenario, appropriate digital technology terminology, high standard of QWC.
Band 1 [3–4 marks]: competent description of at least two of the four security measures, some evaluation, basic terminology, clear presentation.
Band 0 [1–2 marks]: partial description of one or two measures lacking detail, minimal terminology, unclear presentation.
0 marks: no creditworthy content.