CCEA A-Level · Exam Tips

Software Systems Development CL4 Exam Tips

CCEA A2 Software Systems Development is decided by SQL syntax, careful key-tracking through normalisation, and PERT backward-pass arithmetic. This page covers the single 100-mark paper and the mistakes examiner reports flag most.

4 min readUpdated: 3 Sept 2026

Exam at a Glance

Papers
1
Total Marks
100
Time Limit
2h
Question Types
12
PaperDurationMarksQuestionsWeightingQuestion Types
A2 1: Systems Approaches and Database Concepts2h100930%Systems approaches, requirements and project management (Part 1), Relational database concepts, normalisation and SQL (Part 2)
Grade Scale
A*ABCDEU
Calculator Policy

This paper is mostly SQL scripting, diagram work, and extended writing, so a calculator adds little for most of it. The one place arithmetic matters is PERT network questions in the project management content, forward and backward pass totals and float calculations. Calculators are permitted under the standard JCQ rule: no stored, retrievable information of any kind, including formulae, notes, or text, and no symbolic algebra or internet or communication functions. Switch on exam mode if your calculator has one.

  • AO1: AO1: demonstrate knowledge and understanding of concepts, systems approaches, and solutions relevant to software systems development (32%)
  • AO2: AO2: apply their knowledge and understanding to develop and implement solutions to the problems identified (36%)
  • AO3: AO3: analyse and evaluate the concepts of software systems development and candidates' own performance in problem solving (32%)

Built from real past papers and marking schemes (2023–2025).

Tips & Strategies

Where the marks actually go

Unit A2 1, Systems Approaches and Database Concepts, is a single 100-mark paper in 2 hours, built around a pre-release case study you will have seen before the exam. That is about 72 seconds per mark, so a 10-mark question deserves 12 minutes and the 18-mark SQL question at the end deserves close to 22. The paper splits into two halves: Part 1 covers systems approaches, requirements, and project management across six questions worth 55 marks, and Part 2 covers relational databases, normalisation, and SQL across three questions worth 45 marks.

Structured Query Language and entity relationship modelling carry the largest concentrated blocks of marks in Part 2, worth 18 and 17 marks respectively in recent papers, with normalisation close behind. In Part 1, systems methodologies is the heaviest single topic. Because you have already seen the case study before the exam, the marks in both halves reward how precisely you apply your knowledge to the named characters and scenario in it, not how much general theory you can recall.

Paper structure and timing

Part 1: Systems Approaches, Requirements and Project Management (around 55 marks)

Six questions, each worth around 10 marks, mixing short answer and template completion with quality of written communication essays on prototyping, project management, testing and the V-model, and modelling with UML. Budget about 66 minutes across this half, roughly 11 minutes per question.

Part 2: Relational Database Concepts, Normalisation and SQL (around 45 marks)

Three questions: a 10-mark normalisation task taking a relation through 2NF and 3NF, a 17-mark question combining definitions with entity relationship diagram completion, and an 18-mark SQL scripting question covering insertion and multi-table aggregate queries. Budget around 54 minutes, weighted toward the SQL question since it carries the most marks.

Read the pre-release case study again on exam morning, and keep the named characters and business rules from it in front of you. Every extended answer in this paper is marked down when it stays generic instead of naming the specific scenario.

The highest-yield techniques

Normalisation questions are marked step by step, and the most common way to lose marks that have nothing to do with understanding 2NF or 3NF is bookkeeping: forgetting to underline or asterisk primary keys, and forgetting to carry foreign keys forward, at every stage of the decomposition. Mark every key at every step, from the unnormalised form through to 3NF, even when a table looks unchanged from the previous stage.

SQL questions reward precise syntax over approximate logic. When a query needs to find parent records with no matching child rows, for example clients who have never placed an order, use a LEFT JOIN with a null check on the child table's key, an inner join alone will silently exclude exactly the rows the question is asking for. When aggregating, for example summing booking durations by staff member, include every non-aggregate column you are grouping by in the GROUP BY clause, and use COUNT(DISTINCT ...) when a join could otherwise produce duplicate rows.

PERT network questions catch candidates on the backward pass specifically. When more than one activity depends on the same predecessor, the late finish time for that predecessor is the minimum, not the maximum, of the late start times of everything that follows it. Work backward from the project end date one activity at a time, and write down each late start and late finish as you go rather than trying to hold several branches in your head at once.

Quality of written communication questions, on Agile versus Waterfall, feasibility, or testing strategy, lose marks when the answer reads as a textbook definition with no reference to the case study. Name the business, the named characters, and the specific business rule the question is pointing at, and use that context in every paragraph, not just the introduction.

CCEA conventions worth knowing

This unit carries synoptic assessment: A2 questions can draw on material first covered at AS, object concepts, control structures, testing principles, so do not assume everything on this paper is new content from the A2 course alone. Quality of written communication is assessed inside the extended prose questions themselves and depends on specialist technical vocabulary, entity, functional dependency, join, exception, rather than everyday description, plus a logically ordered answer.

The three assessment objectives for this unit are knowledge (AO1), application (AO2), and analysis and evaluation (AO3), weighted at roughly 32%, 36%, and 32% within this paper. That is a more even split than many subjects, which is why both precise recall of syntax and applied problem solving matter equally here.

Exam day plan

Reread the pre-release case study before you open the question paper. For every normalisation step, mark primary and foreign keys as you go, do not leave it to the end. For every SQL query, check your JOIN type and your GROUP BY columns before you move on. For every QWC answer, open with the specific business context, not a general definition. Leave time at the end to check that every extended answer names the case study characters at least once.

Ready to test yourself?

Turn these notes into exam-style practice. Get unlimited AI questions on this topic with instant marking and explanations.

Practise This Topic

Calculator Programmes

PERT forward and backward pass running totals

Purpose: Keep an accurate earliest finish or latest start time on hand as you work through a PERT network diagram's forward and backward pass.

When to use it: For PERT network diagram questions that ask you to complete a forward pass and a backward pass across several activities.

Steps
As you work through the forward pass on your network diagram, key each activity's earliest start plus duration into the calculator and store the result with M+ before moving to the next node, so you always have the previous node's earliest finish on hand. On the backward pass, do the same in reverse, subtracting duration from the smallest late start time among an activity's successors.

Exam note: This only checks your arithmetic once the network diagram itself is drawn correctly by hand. Do not store a pre-built PERT template, macro, or set of formulae in the calculator, CCEA and JCQ rules ban any retrievable information stored in a calculator, and this includes programs as much as text or databanks.

Common Mistakes

  1. 1highMarks at stake: 2Normalisation

    Forgetting to mark primary and foreign keys, with asterisks or underlining, at every stage of decomposing a relation into 2NF and 3NF.

    How to avoid it: Re-mark every key at every step of the normalisation, even for a table that looks unchanged from the previous stage. Losing the key markers loses marks separately from getting the normal form itself right.
  2. 2mediumMarks at stake: 1Structured Query Language (SQL)

    Writing SQL CHECK constraints with incorrect syntax, for example omitting the equality operator when checking that a delivery date is on or after an order date.

    How to avoid it: Write comparison operators out fully, greater than or equal to, not just greater than, when a business rule allows the two dates to match.
  3. 3highMarks at stake: 3Structured Query Language (SQL)

    Using an inner join to find parent records with no matching child rows, which silently excludes exactly the records the question is asking for.

    How to avoid it: Use a LEFT JOIN from the parent table and add a WHERE clause checking that the child table's key IS NULL to isolate unmatched parent rows.
  4. 4highMarks at stake: 4Managing projects

    Miscalculating a PERT backward pass when more than one successor activity converges on the same predecessor, by using the wrong one of the competing late start times.

    How to avoid it: When several activities depend on the same predecessor, its late finish time is the smallest of their late start times, not the largest. Work backward one node at a time and write each value down.
  5. 5highMarks at stake: 3Systems methodologies

    Writing a generic, textbook-style answer to a quality of written communication question, such as Agile versus Waterfall or a feasibility study, without linking it to the pre-release case study.

    How to avoid it: Name the business and the specific characters or business rule from the case study in your opening sentence, and keep referring back to them through the answer.
  6. 6highMarks at stake: 2Structured Query Language (SQL)

    Leaving non-aggregate attributes out of the GROUP BY clause when writing an SQL query that sums or counts values across a joined table.

    How to avoid it: List every selected column that is not inside an aggregate function in the GROUP BY clause, and use COUNT(DISTINCT ...) if a join could produce duplicate rows for the same entity.
  7. 7mediumMarks at stake: 2Testing

    Confusing extreme test data, valid values at the edge of an acceptable range, with erroneous test data, values of the wrong type or outside the range entirely.

    How to avoid it: Keep the two categories separate in a test plan: extreme data should be accepted by the system, erroneous data should be rejected. State the expected outcome for each row.
  8. 8mediumMarks at stake: 1Structured Query Language (SQL)

    Getting the argument order wrong in SQL date functions such as DATEDIFF or DATEADD, which reverses the sign of the result.

    How to avoid it: Check the specific date function's parameter order before the exam and write it from memory correctly, start date and end date are not interchangeable in DATEDIFF.

Turn these tips into top grades

thinka turns your weak spots into targeted practice, with instant marking and exam-style feedback. Study smarter, not longer.

Practise real exam questions with instant AI feedback and marking.

Start Practising Free