A-Level Revision Aid: This resource is designed to support your revision. Content may contain errors. If you find a discrepancy with your class teaching, your teacher is correct — please let us know at alevelrevise@scott.scottrix.co.uk.
Software Development and Legal Issues
Year 1 / ASYear 2 / A-LevelAQA, OCR, WJEC/Eduqas
Exam-focused AQA 7517, OCR H446 and WJEC/Eduqas revision for software development and legal issues: SDLC models, programming paradigms and OOP, translators, testing, and the legal/ethical framework (Data Protection, Computer Misuse) with evaluation points.
🎯 Learning Objectives
Compare SDLC models (waterfall, agile, spiral, incremental) and justify a choice for a given project scenario (OCR 1.2.4, AQA 4.9/4.12)
Explain the stages of a systematic approach to problem solving: analysis, design, implementation, testing, evaluation (AQA 4.9)
Describe programming paradigms — procedural and object-oriented — and apply OOP: classes, encapsulation, inheritance, polymorphism (OCR 1.2.6, WJEC Unit 4)
Compare compilers, interpreters and assemblers, and explain bytecode and virtual machines (OCR 1.2.3, AQA 4.4)
Describe testing levels (unit, integration, alpha, beta, acceptance) and types (white box, black box), and select test data (normal, boundary, erroneous) (OCR 1.2.4, AQA 4.9)
Explain the legal framework: Data Protection Act 2018, Computer Misuse Act 1990, Copyright Designs and Patents Act 1988, Regulation of Investigatory Powers Act 2000 (OCR 1.5)
Discuss ethical and professional issues in software development, including privacy and non-functional requirements (AQA 4.10, OCR 1.5)
📋 Key Definitions and Core Concepts
SDLC: Software Development Life Cycle: the structured stages a software project passes through — analysis, design, implementation, testing, evaluation/maintenance.
Waterfall model: A linear SDLC where each stage completes before the next begins; requirements are fixed up front, so change is expensive.
Agile development: An iterative SDLC delivering working software in short sprints, embracing changing requirements and continuous customer feedback.
Prototype: An early, partial version of a system built to clarify requirements or demonstrate feasibility before full development (AQA 4.12).
Paradigm: A style or model of programming: procedural (sequence of subroutine calls), object-oriented (objects exchanging messages), declarative/functional.
Class: A template defining the attributes (data) and methods (behaviour) of a type; an object is an instance of a class.
Encapsulation: Binding attributes and methods together in a class and hiding internal state (private attributes) behind a public interface.
Inheritance: A subclass deriving attributes and methods from a superclass, adding or overriding behaviour; an is-a relationship.
Polymorphism: The same method call behaving differently depending on the object's actual class — each subclass overrides the method with its own implementation.
Compiler vs interpreter: A compiler translates the whole program to machine code before execution (fast execution, one build); an interpreter translates and executes line by line at run time (slower, immediate errors).
Spiral: risk-driven iterations (risk analysis each loop); incremental: deliver in stages, each adding functionality
OOP: class = attributes + methods; encapsulation hides state, inheritance reuses (is-a), polymorphism = one call, many behaviours (OCR 1.2.6)
Compiler: whole-program translation before run — fast execution; interpreter: line-by-line at run time — immediate error reporting; assembler: assembly to machine code (OCR 1.2.3)
Test data: normal (valid), boundary (edges of valid ranges), erroneous (invalid — must be rejected); white box tests internal paths, black box tests behaviour only
The SDLC (OCR 1.2.4, AQA 4.9) is the sequence of stages every project passes through: analysis (establish requirements with the client — the problem, not the solution), design (data structures, algorithms, module structure, UI), implementation (coding to the design), testing (verifying against the requirements), evaluation (does it meet the original goals?) and maintenance (AQA 4.11: corrective — fixing bugs found in use; adaptive — responding to changed environments; perfective — improving it beyond the original spec).
Waterfall runs the stages linearly, each completing before the next begins. Strengths: simple to manage, clear milestones, thorough documentation, suits projects with fixed, well-understood requirements (contracted, safety-critical, regulatory). Weaknesses: requirements are frozen up front, so late feedback; a wrong decision in analysis propagates; the customer sees nothing working until the end; change is expensive. The exam one-liner: waterfall assumes requirements are known and stable — it fails when they change.
Agile develops in short iterations (sprints, typically 1–4 weeks), each delivering a working increment reviewed by the customer; requirements are re-prioritised every sprint. Strengths: working software early and often, welcomes changing requirements, continuous customer feedback, risks surface early. Weaknesses: needs constant customer involvement, less predictable final cost/timeline, documentation can be thin, harder to contract. Exam one-liner: agile assumes requirements will change — it embraces that with iteration.
Spiral loops through planning, risk analysis, engineering and evaluation — each loop addressing the biggest current risk; suited to large, high-risk projects where risk analysis per iteration is worth its cost. Incremental delivers the system in stages, each adding functionality to a working core; overlaps with agile but without mandating short sprints or customer ceremonies. Prototyping (AQA 4.12) builds an early partial version — throwaway prototypes clarify requirements and are discarded; evolutionary prototypes grow into the final system; both reduce the risk of building the wrong thing.
The 9-marker this topic almost always takes: 'Explain why organisation X should use [model] for project Y.' The full-credit structure: (1) identify Y's defining characteristic — requirements stable or changing? deadline or budget fixed? high-risk? (2) match the model: fixed requirements → waterfall; changing requirements/unclear needs → agile or prototyping; high-risk → spiral; (3) justify with two consequences of the match (e.g. agile delivers working increments early so the client can course-correct, avoiding building the wrong product); (4) concede one weakness and why it is tolerable here. An A* answer argues both sides before concluding. Example conclusion: a startup building an app with unclear market fit should use agile — requirements will change as users give feedback, and short sprints mean the product pivots cheaply; waterfall's frozen requirements would bake in early guesses, and its single end-of-project delivery would arrive after the market moved.
Programming paradigms and OOP
A paradigm (OCR 1.2.6) is a style of programming. The examinable set: procedural — programs as sequences of subroutine calls over shared data; object-oriented — programs as interacting objects, each bundling data and behaviour; declarative/functional — programs as expressions and function applications (AQA 4.8: map, filter, fold/reduce), stating what not how. The comparison to quote: procedural suits problems modelled as step-by-step algorithms; OOP suits systems with many entity types interacting (GUIs, simulations, games); functional suits data transformation pipelines.
OOP concepts (OCR 1.2.6, WJEC Unit 4) — learn each with its one-line benefit:
Class and object: a class defines attributes + methods; an object is an instance. Benefit: one definition, many instances.
Encapsulation: attributes are private; access goes through public methods (getters/setters). Benefit: internal state cannot be corrupted by outside code; the implementation can change without breaking callers — the class maintains its own invariants (e.g. a setter rejects negative balances).
Inheritance: a subclass extends a superclass (an is-a relationship), reusing its attributes and methods and adding/overriding. Benefit: code reuse; a common interface over related types.
Polymorphism: the same method call behaves differently per actual class — each subclass overrides the method. Benefit: code written against the superclass works for all subclasses without conditionals.
Worked example — the classic exam design (vehicles):
class Vehicle:
def __init__(self, wheels):
self.wheels = wheels # private in spirit
def describe(self):
return 'Vehicle with ' + str(self.wheels) + ' wheels'
class Car(Vehicle): # Car is-a Vehicle (inheritance)
def __init__(self, wheels, plates):
super().__init__(wheels)
self.plates = plates
def describe(self): # overridden (polymorphism)
return 'Car, ' + str(self.wheels) + ' wheels, plate ' + self.plates
vehicles = [Car(4, 'AB12 CDE'), Vehicle(2)]
for v in vehicles:
print(v.describe()) # one call, two behaviours
Trace: the loop calls describe() on each element without knowing its class; Python dispatches to the actual class's method — output 'Car, 4 wheels, plate AB12 CDE' then 'Vehicle with 2 wheels'. That is polymorphism: the call site is unchanged whether the list holds cars, bikes or trucks — adding a new subclass requires no change to this code, which is the evaluation point examiners want (open/closed principle in spirit).
Exam patterns: 'Explain the difference between a class and an object' (class is the template, object is an instance of it); 'Explain why encapsulation improves maintainability' (state is accessed only through methods, so the representation can change freely and invalid values are rejected at the boundary); 'Explain what is meant by inheritance and state one benefit' (subclass derives from superclass, is-a; benefit: reuse of attributes/methods and a common interface). Full marks consistently require the benefit sentence, not just the definition.
Translators: compilers, interpreters, assemblers
High-level languages must be translated to machine code (OCR 1.2.3, AQA 4.4). The three translators and their trade-offs:
Compiler: translates the whole program to machine code before execution. Fast execution (native code, translated once); reports all syntax errors after a full compile; errors listed with line numbers; the executable runs without the compiler or source. Slower development loop — recompile after every change; error messages can be less immediate.
Interpreter: translates and executes line by line at run time. Execution is slower (re-translated every run); stops at the first error — excellent for debugging and learning; needs the interpreter present on every machine. Development is fast: run immediately, no build step.
Assembler: translates assembly language (mnemonics such as LDA, ADD) one-to-one into machine code — low level, processor-specific.
The comparison to reproduce: 'Explain the difference between a compiler and an interpreter.' Model phrasing: a compiler translates the entire source program into machine code before execution, producing an executable that runs quickly and independently of the compiler, and reporting syntax errors after a full pass; an interpreter translates and executes statements one at a time at run time, so execution is slower but errors are reported immediately and no build step is needed.
Bytecode and virtual machines — the A* extension: languages such as Java compile source to bytecode, an intermediate representation executed by the Java Virtual Machine (a bytecode interpreter/JIT compiler). The benefit: platform independence — 'write once, run anywhere': one compiled artefact runs on any machine with a JVM, because the JVM adapts the final translation to each processor. The cost: an extra execution layer, so slower than fully native compilation (partly recovered by JIT). Exam pattern: 'Explain why Java programs can run on many different processors.' Answer: source is compiled to bytecode, an intermediate form not tied to any processor; the JVM on each platform translates bytecode to that processor's machine code at run time, so the same bytecode runs wherever a JVM exists.
Also be ready to link translators to the FDE cycle: whatever the translator, the processor ultimately executes machine code fetched instruction by instruction — assembly language is the human-readable form of exactly those instructions (opcode + operand), one mnemonic per machine instruction for the target architecture.
Testing: levels, types and test data
Testing levels (OCR 1.2.4, AQA 4.9) — learn the ladder and what each catches:
Unit testing: each subroutine tested in isolation with known inputs and expected outputs — catches logic errors early, where they are cheapest to fix.
Integration testing: modules tested together — catches interface errors: mismatched parameters, wrong data formats between modules, assumptions one module makes about another.
Alpha testing: in-house testing by the development team on the complete system.
Beta testing: released to real users outside the team — catches usage patterns and environment differences in-house testing cannot reproduce.
Acceptance testing: the customer verifies the system meets the agreed requirements before sign-off.
The exam pattern: 'Explain why unit testing alone is not sufficient.' Answer: units can each pass while the system fails — interface errors between them (mismatched parameters, incompatible data formats, misread return values) are only found when modules are tested together, which is integration testing's purpose; and only beta/acceptance testing exposes real-user conditions.
Test types:black box testing supplies inputs and checks outputs without seeing the code — testing the specified behaviour; white box (structural) testing designs tests from the code itself, aiming to exercise every branch and path (each if-side, each loop exit). The comparison: white box can prove all paths execute but only tests what the code does (bugs of omission escape); black box tests the requirement but may miss internal branches. Test data — three categories, the guaranteed exam question:
Normal: valid, typical values — a mark of 65 in 0–100.
Boundary: the edges of validity — 0, 1, 99, 100 for the range 0–100 (and just outside: −1, 101, catching off-by-one errors).
Erroneous: invalid input that must be rejected — 'abc', 150, −5; the program must reject gracefully, not crash.
Exam pattern: 'A program validates an age between 13 and 19 inclusive. State the test data you would use and the expected outcome for each.' Answer: normal — 16 (accepted); boundary — 13, 19 (accepted), 12, 20 (rejected — just outside catches off-by-one comparison errors); erroneous — 'abc', negative numbers (rejected with an error message). The boundary-just-outside values are what earn the top marks, because they detect the classic < vs <= error.
Test-driven development (TDD) — write the test first, watch it fail, write the minimum code to pass, refactor. The benefit to quote: tests encode the requirements before implementation, so the code is verified against the spec continuously and regressions are caught the moment they appear; the cost: more up-front effort, and tests can encode a wrong understanding of the spec as faithfully as the code would.
Legal and ethical issues
Four UK laws cover the examined ground (OCR 1.5, WJEC 1.10) — learn each with its scope and a scenario:
Data Protection Act 2018 / UK GDPR: governs personal data — data relating to identifiable living individuals. Principles: data must be processed lawfully, fairly and transparently; collected for specified purposes; kept accurate and up to date; kept no longer than necessary; kept secure; and transferred only with adequate protection. Individuals' rights: access their data, correction, erasure. Scenario: a company storing customer records must secure them and delete them when no longer needed; a breach must be reported.
Computer Misuse Act 1990: three offences: unauthorised access (accessing someone else's account/system — even without damage); unauthorised access with intent to commit further crime; unauthorised modification (viruses, ransomware, altering data). Scenario: guessing a friend's password is the first offence; deploying ransomware is the third.
Copyright, Designs and Patents Act 1988: protects creative works including software — copying or distributing software without a licence is illegal; proprietary licences restrict use/copying, open-source licences (GPL, MIT) grant it under conditions.
Regulation of Investigatory Powers Act 2000 (RIPA): governs surveillance and interception of communications by public bodies — when and how communications data may be accessed and warrants obtained.
Exam pattern: 'State the legislation that covers [scenario] and explain its relevance.' Answer structure: name the Act precisely (with year), state its scope in one line, apply it: e.g. an employee accessing customer records without authorisation — Computer Misuse Act 1990, unauthorised access offence; if they then copy the records, Data Protection Act 2018 governs how that personal data may be processed.
Ethical issues beyond the law — the evaluation questions ('discuss the ethical issues...') reward balance. The standard axes: privacy (collecting more personal data than necessary; tracking; surveillance vs security benefits), employment (automation displacing roles while creating others), bias and fairness (machine-learning systems trained on biased data making discriminatory decisions), digital divide (unequal access to technology), environmental (energy use of data centres and crypto-mining), and professional behaviour (ACM/BCS codes of conduct: competence, honesty, public interest). The A* structure: give both sides (benefit and harm), then a reasoned judgement: e.g. a facial-recognition system in schools — benefit: security and safeguarding; harms: privacy of minors, consent issues, biased accuracy across demographics; judgement: the intrusion must be proportionate to the benefit, with consent and independent oversight.
Non-functional requirements (AQA 4.10) tie the section together: the qualities beyond function the system must meet — performance (response times), usability, security, reliability, capacity, maintainability. The exam point: functional requirements say what the system does; non-functional say how well it must do it, and they are measurable — 'respond within 2 seconds' is testable, 'must be fast' is not. Ethical and legal compliance (DPA security principle, accessibility) are themselves non-functional requirements a design must state explicitly to be evaluated.
💡 Worked Example
Exam-style: A charity is commissioning a database-driven membership system. Requirements are expected to change frequently as the charity grows, and the trustees want to see working software early.
(a) Explain why an agile SDLC is more suitable than a waterfall model for this project. [6 marks]
(b) State one weakness of the agile approach and explain how the charity could mitigate it. [2 marks]
Mark-scheme logic: (a) Agile develops the system in short iterative sprints, each delivering working software reviewed by the customer (1). This matches the scenario: requirements are expected to change frequently, and agile re-prioritises requirements each sprint so change is embraced rather than treated as a costly deviation (1). The trustees want early visibility: each sprint ends with a working increment, so they see progress within weeks rather than at a single end-of-project delivery (1). By contrast, waterfall freezes requirements in analysis and completes each stage fully before the next (1), so frequent change would force expensive rework and the charity would not see working software until the end (1). Conclusion: agile's iteration aligns with both the changing requirements and the desire for early, reviewable deliveries (1).
(b) Agile's documentation can be thinner and final cost/timeline less predictable (1). Mitigation: agree a fixed sprint budget with review gates each sprint, and maintain minimal living documentation (e.g. up-to-date requirements backlog) so knowledge is not lost between iterations (1).
❓ Practice Questions & Mark Schemes
Explain the difference between a compiler and an interpreter. [4 marks]
Answer: A compiler translates the entire source program into machine code before execution (1), producing an executable that runs fast, translated once, and reporting syntax errors after a full compile pass (1). An interpreter translates and executes statements one at a time at run time (1), so execution is slower and the interpreter must be present to run the program, but errors are reported immediately as each line is reached — useful for debugging and development (1).
A program validates a mark between 0 and 100 inclusive. State the normal, boundary and erroneous test data you would use, with the expected outcome for each. [6 marks]
Answer: Normal: 65 — valid and typical, accepted (2 marks: normal data + outcome). Boundary: 0 and 100 — the edges of validity, accepted; also −1 and 101 — just outside, rejected; these catch off-by-one errors such as using < instead of <= (2 marks: boundary values including just-outside + outcomes). Erroneous: 'abc' or 150 — invalid input that must be rejected gracefully with an error message, not crash (2 marks: erroneous data + rejection behaviour).
Explain what is meant by polymorphism in object-oriented programming and state one benefit. [4 marks]
Answer: Polymorphism is when the same method call behaves differently depending on the actual class of the object — each subclass overrides the superclass's method with its own implementation (2 marks: overriding + dispatch on actual class). Benefit: code written against the superclass works for every subclass without conditional checks, so new subclasses can be added without modifying the calling code (1), improving extensibility and reducing duplicated selection logic (1).
State the three offences under the Computer Misuse Act 1990 and give an example of each. [3 marks]
Answer: Unauthorised access — e.g. accessing another person's account or system without permission (1). Unauthorised access with intent to commit a further offence — e.g. hacking into a system in order to steal banking details (1). Unauthorised modification — e.g. deploying a virus or ransomware that alters or destroys data (1).
Explain why unit testing alone is not sufficient to verify a complete system. [3 marks]
Answer: Unit tests check each subroutine in isolation, so each can pass while the assembled system fails (1). Interface errors between modules — mismatched parameters, incompatible data formats, wrong assumptions about return values — only appear when modules are tested together (1). Integration testing (and later alpha/beta testing) is needed to expose those interaction faults and real-usage conditions (1).
A company stores customer records including names, addresses and purchase history. Name the legislation governing this data and explain two of its principles the company must follow. [4 marks]
Answer: Data Protection Act 2018 / UK GDPR (1). Principle 1: personal data must be processed lawfully, fairly and transparently and collected for specified purposes — the company must have a lawful basis and tell customers what is collected and why (1). Principle 2: data must be kept accurate, secure and no longer than necessary — records must be corrected on request, protected against breach, and deleted when no longer needed (1). One further point: individuals have rights of access, correction and erasure the company must honour (1).
amazon.co.uk
