2025 CCEA A-Level Software Systems Development CL4 模擬試題連答案詳解

(a) Three suitable fact-finding techniques: (1) Interviews — one-to-one or small-group discussions with staff (e.g. Priya and shop assistants) to explore in depth how orders and stock are currently handled; advantage: allows follow-up questions, so the analyst can clarify ambiguous or complex points about how the card index is updated. (2) Questionnaires — short, structured forms given to GreenLeaf's ~400 regular customers; advantage: can gather a large amount of standardised data quickly and cheaply, showing which features (e.g. online stock checking) customers would value most, without requiring the analyst's time for each response. (3) Observation — the analyst watches staff process a paper order and update the card index in real time; advantage: reveals the actual working process (including informal workarounds), which staff may not think to mention in an interview because it has become routine to them. (b) Two example user stories, each following the template exactly and grounded in the case study: User story 1 — 'As a sales assistant, I want to check live plant stock levels, so that I can tell a customer whether an item is in stock without walking to the nursery.' User story 2 — 'As the manager, I want to see a report of best-selling plants, so that I can decide what to reorder from suppliers.' Answer: any three valid fact-finding techniques with context-specific advantages, and any two well-formed, case-study-grounded user stories in the given template.

(a) [6]: 2 marks per technique — [1] for correctly naming/describing the technique, [1] for a valid advantage specific to GreenLeaf's context (a generic advantage with no case study link scores 0 for that mark). Accept any three of: interviews, questionnaires, observation, document analysis (of existing paper order forms/card index), or record inspection. (b) [4]: 2 marks per user story — [1] for correct template format (role/goal/benefit all present and grammatically coherent), [1] for a goal and benefit that are both realistic and clearly grounded in the GreenLeaf case study (e.g. referencing stock checking, orders, or reporting). Award 0 for a story with no case-study relevance.

Description 1 describes Waterfall: a traditional, sequential methodology where phases (requirements → design → build → test → implementation) are completed in strict order with formal sign-off before moving on, making it unsuitable for GreenLeaf if requirements are likely to change during development. Description 2 describes DSDM (Dynamic Systems Development Method): it is defined by its use of timeboxing (fixed deadlines for each stage) and the MoSCoW prioritisation technique, guaranteeing a usable system is delivered on time even if lower-priority ('Could have'/'Won't have') features are dropped. Description 3 describes SCRUM: its defining features are fixed-length sprints, a prioritised product backlog, and short daily 'stand-up' meetings (daily scrums) to track progress. Description 4 describes XP (Extreme Programming): its hallmark practices are pair programming, test-driven development (writing tests before code), and continuous integration/testing. Description 5 describes RAD (Rapid Application Development): it is characterised by heavy use of prototyping and reusable components with intensive user involvement, aiming to deliver a working system within a very short timescale. Answer: 1=Waterfall, 2=DSDM, 3=SCRUM, 4=XP, 5=RAD.

1 mark for each correctly matched description, to a maximum of 5 marks. No partial credit within a single description; each description has exactly one correct methodology from the given list.

(a) Prototyping is the process of building an early, simplified, working version of a system (or part of it) — for example a mock-up of the screen a sales assistant would use to check plant stock — which demonstrates its look, feel and/or core functionality without being the final, fully built product. It is shown to users, who try it out and give feedback, which developers use to refine the requirements or design before committing to full development. (b) Prototyping could help GreenLeaf's team in several ways. First, because current staff and customers are used to a paper-based system, they may struggle to describe in the abstract what they want from a new computerised system; a working prototype of, for example, the stock-checking screen lets a sales assistant try searching for a plant by name and immediately say whether the process feels faster and clearer than the card index, surfacing requirements that would not have emerged from an interview alone. Second, prototyping can expose misunderstandings early: if the analyst had wrongly assumed staff only needed to see stock quantity, showing a prototype might prompt a member of staff to point out they also need to see which supplier restocks a particular plant, allowing the requirement to be corrected before significant development time is invested. Third, showing prototypes to a sample of GreenLeaf's regular customers (for example, a simple order-entry screen) could reveal whether customers find the ordering process confusing, allowing usability issues to be fixed cheaply at the design stage rather than after full implementation, when changes are far more costly to make. Answer: prototyping is an early, working model of a system built to gather user feedback before full development; for GreenLeaf, it would let staff and customers react to concrete stock-checking and ordering screens, surfacing missing requirements and usability problems early and cheaply.

(a) [4]: up to 4 marks — [1-2] partial definition (e.g. 'a working model of a system'); [3-4] full definition covering an early/incomplete working model, demonstrating look/feel/functionality, AND its purpose of gathering user feedback before full build. (b) [6], 3-tier Level-of-Response: Level 1 (1-2 marks) — basic overview of prototyping's benefit, minimal case study linkage, limited specialist vocabulary. Level 2 (3-4 marks) — good explanation with clear linkage to GreenLeaf's staff/customers, adequate structure and terminology. Level 3 (5-6 marks) — comprehensive, well-organised discussion with thorough integration of specific GreenLeaf examples (e.g. stock-checking screen, order-entry screen) and fluent technical vocabulary.

(a) Statement 1 is FALSE: the critical path is the sequence of dependent tasks with the LONGEST total duration through the project network, not the shortest — it determines the minimum possible time in which the whole project can be completed, and any delay to a task on it delays the whole project. Statement 2 is TRUE: float (or slack) is exactly the spare time a non-critical task has — it can be delayed by up to that amount without pushing back the project's overall completion date. Statement 3 is FALSE: that description matches a PERT/network diagram, not a Gantt chart; a Gantt chart is a horizontal bar chart plotting tasks against a timeline (with bar length showing duration), and while some Gantt charts show simple dependency links between bars, its primary purpose is to display scheduling against time, not to model a logical network of nodes and arrows. Statement 4 is TRUE: a milestone marks a significant point in a project (e.g. 'database design signed off') and, by definition, has zero duration itself — it is an event, not a task. (b) A Gantt chart would help GreenLeaf's project manager in several ways. It provides a single visual timeline showing when each stage of development — for example fact-finding, database design, building the ordering screens, and testing — should start and finish, making it easy to see at a glance whether tasks (such as designing the PLANT and ORDER tables) can run in parallel with others (such as staff training material being prepared) or must wait until a previous task, like requirements sign-off, is complete. It also lets the manager monitor progress by comparing actual progress bars against the planned schedule, so if database design overruns, the manager can immediately see the knock-on effect on the planned start date for coding and testing, and can decide whether to reallocate resources or adjust the plan. Finally, marking milestones on the Gantt chart (such as 'prototype approved by Priya') gives the team and stakeholders clear checkpoints to confirm the project for GreenLeaf is on track before the next phase of work begins. Answer: 1=False (critical path is the longest path), 2=True, 3=False (that describes a network/PERT diagram), 4=True; a Gantt chart helps GreenLeaf's manager sequence tasks, spot parallel work, monitor progress against plan, and track milestones.

(a) [4]: 1 mark per correct True/False judgement, to a maximum of 4 marks; no marks for justification required in part (a) alone. (b) [6], 3-tier Level-of-Response: Level 1 (1-2 marks) — basic overview, minimal case study linkage, limited specialist vocabulary. Level 2 (3-4 marks) — good explanation, clear linkage to GreenLeaf's project, adequate structure and terminology. Level 3 (5-6 marks) — comprehensive, well-organised discussion with thorough integration of specific GreenLeaf examples (e.g. named tasks/milestones) and fluent technical vocabulary.

(a) In the V-Model, each stage on the descending (development) side of the V is mirrored by a corresponding stage on the ascending (testing) side, with Coding at the bottom vertex: Requirements Analysis pairs with Acceptance Testing (Blank 1) — checking the finished system meets the users' original requirements; System Design pairs with System Testing (Blank 2 fills the development side here) — checking the whole system works together as designed; Architectural Design pairs with Integration Testing — checking that major components/modules work together correctly; Module (Detailed) Design pairs with Unit Testing (Blank 3 fills the development side) — checking individual modules/units work correctly in isolation; and Unit Testing (Blank 4) is the testing stage that begins immediately after Coding, at the bottom of the V, before integration testing follows. (b) The V-Model would help GreenLeaf's team by ensuring a test plan is designed alongside each development stage, rather than being left until the end. For example, because Acceptance Testing is planned at the same time as Requirements Analysis, the team would define upfront, precise, checkable criteria — such as 'a sales assistant must be able to find a plant's stock level in under 10 seconds' — directly from GreenLeaf staff's requirements, meaning the finished system is tested against what users actually asked for, not just against the final code. Similarly, planning Unit Testing alongside Module Design means each part of the system, such as the routine that calculates a customer's order total, is tested in isolation early, so an error is caught and fixed while it is still cheap to correct, rather than being discovered only when the whole system is tested together. Overall, the V-Model's structure reduces the risk that GreenLeaf receives a system that technically works but does not do what Priya and her staff actually need, because every development stage has a matching, planned verification stage. Answer: Blank 1=Acceptance Testing, Blank 2=System Design, Blank 3=Module (Detailed) Design, Blank 4=Unit Testing; the V-Model helps GreenLeaf by pairing each development stage with planned testing against the original requirements, catching errors early and cheaply.

(a) [4]: 1 mark per correctly completed blank, to a maximum of 4 marks. Accept 'Detailed Design' or 'Module Design' interchangeably for Blank 3. (b) [6], 3-tier Level-of-Response: Level 1 (1-2 marks) — basic overview, minimal case study linkage, limited specialist vocabulary. Level 2 (3-4 marks) — good explanation, clear linkage to GreenLeaf's system, adequate structure and terminology. Level 3 (5-6 marks) — comprehensive, well-organised discussion thoroughly integrating specific GreenLeaf examples (e.g. named test criteria, named modules) with fluent technical vocabulary.

(a) The most appropriate diagram is a Sequence Diagram. A Sequence Diagram is specifically designed to show the time-ordered sequence of messages passed between objects during a particular interaction or use case, with objects arranged across the top and vertical 'lifelines' showing the order in which messages occur over time. This matches the requirement precisely, since the analyst needs to capture the order in which events happen — the customer selecting plants, the system checking stock, and the system confirming the order — rather than simply which actors interact with the system in general (which would be better suited to a Use Case Diagram) or the static structure of the system's classes (a Class Diagram). (b) A UML diagram, being a standardised, widely recognised visual notation, would help GreenLeaf's team communicate the system design clearly to different audiences. For technical developers, a Sequence Diagram of the order process gives an unambiguous, precise specification of which system component is responsible for each step (e.g. that the ordering module must call the stock-checking module before confirming the order), reducing the risk of two developers building inconsistent parts of the system. For non-technical stakeholders such as Priya, who is not a software specialist, a simplified diagram — for example a Use Case Diagram showing 'Customer' and 'Staff' as actors connected to ovals such as 'Place Order' and 'Check Stock' — provides an accessible, visual overview of what the system will do, without requiring her to read technical code or detailed written specifications, making it easier for her to confirm the design matches what GreenLeaf actually needs before development begins, and to spot at a glance if an important interaction (such as checking supplier stock levels) has been missed. Answer: a Sequence Diagram is the most appropriate choice, as it models time-ordered interactions; UML diagrams generally help GreenLeaf's team by giving developers an unambiguous technical specification and giving non-technical stakeholders like Priya an accessible visual overview to confirm the design meets the business's needs.

(a) [4]: [1-2] for correctly identifying 'Sequence Diagram' with minimal justification; [3-4] for the correct diagram AND a justification that explicitly references the time-ordered/message-passing nature of a sequence diagram (not merely 'it shows the process'). A well-justified alternative such as Activity Diagram (models workflow/sequence of activities) may be credited at markers' discretion if the justification is technically accurate, but Sequence Diagram is the expected best-fit answer. (b) [6], 3-tier Level-of-Response: Level 1 (1-2 marks) — basic overview, minimal case study linkage, limited specialist vocabulary. Level 2 (3-4 marks) — good explanation, clear linkage to GreenLeaf's stakeholders, adequate structure and terminology. Level 3 (5-6 marks) — comprehensive, well-organised discussion distinguishing technical vs non-technical stakeholder needs with specific GreenLeaf examples and fluent technical vocabulary.

(a) 2NF removes partial dependencies — attributes that depend on only part of the composite key (OrderID, PlantID) rather than the whole key. OrderDate, CustomerID, CustomerName and CustomerEmail depend only on OrderID, so they are moved to a new ORDERS table. PlantName and UnitPrice depend only on PlantID, so they are moved to a new PLANT table. Quantity depends on the whole composite key (a specific plant on a specific order), so it stays, with the composite key, in ORDER_LINE. Result: ORDERS(OrderID (PK), OrderDate, CustomerID*, CustomerName, CustomerEmail); PLANT(PlantID (PK), PlantName, UnitPrice); ORDER_LINE(OrderID* (PK), PlantID* (PK), Quantity). (b) 3NF removes transitive dependencies — non-key attributes that depend on another non-key attribute rather than directly on the primary key. In the 2NF ORDERS table, CustomerName and CustomerEmail depend on CustomerID, not directly on OrderID (OrderID -> CustomerID -> CustomerName/CustomerEmail is transitive), so they are moved to a new CUSTOMER table, leaving only CustomerID as a foreign key in ORDERS. PLANT and ORDER_LINE contain no transitive dependencies, so they are unchanged. Result: ORDERS(OrderID (PK), OrderDate, CustomerID*); CUSTOMER(CustomerID (PK), CustomerName, CustomerEmail); PLANT(PlantID (PK), PlantName, UnitPrice); ORDER_LINE(OrderID* (PK), PlantID* (PK), Quantity). Answer: 3NF = ORDERS(OrderID (PK), OrderDate, CustomerID*) + CUSTOMER(CustomerID (PK), CustomerName, CustomerEmail) + PLANT(PlantID (PK), PlantName, UnitPrice) + ORDER_LINE(OrderID* (PK), PlantID* (PK), Quantity).

(a) [5]: [1] ORDER_LINE(OrderID*, PlantID*, Quantity) correctly shown with composite PK; [1] PLANT(PlantID (PK), PlantName, UnitPrice) correctly separated; [1] ORDERS(OrderID (PK), OrderDate, CustomerID*, CustomerName, CustomerEmail) correctly separated at this stage; [1] correct identification that PlantName/UnitPrice and OrderDate/CustomerID/CustomerName/CustomerEmail were partial dependencies (only depend on part of the composite key); [1] correct PK/FK notation (uppercase table names, PK labelled, FK flagged with ) throughout. (b) [5]: [1] CUSTOMER(CustomerID (PK), CustomerName, CustomerEmail) correctly created; [1] ORDERS correctly reduced to (OrderID (PK), OrderDate, CustomerID); [1] correct identification of the transitive dependency (CustomerName/CustomerEmail depend on CustomerID, not OrderID); [1] PLANT and ORDER_LINE correctly carried forward unchanged; [1] correct, consistent PK/FK notation across all four final tables. Accept equivalent correct table/attribute names if functionally identical to the model answer.

(a)(i) An entity is a distinct object, person, place or thing about which an organisation needs to store data, and which is represented as a table in a relational database, with each row (record) representing one instance of that entity; for example, PLANT is an entity in GreenLeaf's system, representing each distinct plant the garden centre sells. (ii) A one-to-many relationship exists where a single occurrence of one entity can be associated with many occurrences of a second entity, but each occurrence of the second entity is associated with only one occurrence of the first. In GreenLeaf's system, one SUPPLIER can supply many different PLANTs, but each individual PLANT is sourced from only one SUPPLIER, so the relationship from SUPPLIER to PLANT is one-to-many. (b) Blank A = CUSTOMER (a customer places many orders, but each order is placed by one customer); Blank B = ORDER_LINE (an order contains many order lines, one for each different plant ordered); Blank C = PLANT (a plant appears in many order lines, across many different orders); Blank D = PLANT (a supplier supplies many plants). Cardinalities and justifications: CUSTOMER-ORDERS is one-to-many, because one customer (e.g. J. Wilson) can place many orders over time, but each individual order is placed by exactly one customer. ORDERS-ORDER_LINE is one-to-many, because one order can contain several order lines (one per distinct plant ordered), but each order line belongs to exactly one order. PLANT-ORDER_LINE is one-to-many, because one plant (e.g. Lavender) can appear in many order lines across different customers' orders, but each order line refers to exactly one plant. SUPPLIER-PLANT is one-to-many, because one supplier can supply many different plants to GreenLeaf, but each plant is sourced from exactly one supplier. Note that the underlying customer-to-plant relationship is genuinely many-to-many (a customer can order many plants, and a plant can be ordered by many customers), which is why it is correctly resolved into two one-to-many relationships meeting at the linking entity ORDER_LINE, rather than modelled directly. Answer: Blank A=CUSTOMER, Blank B=ORDER_LINE, Blank C=PLANT, Blank D=PLANT; all four relationships (CUSTOMER-ORDERS, ORDERS-ORDER_LINE, PLANT-ORDER_LINE, SUPPLIER-PLANT) are one-to-many.

(a) [5]: (i) [2] — [1] partial definition (e.g. 'a thing you store data about'); [2] full definition referencing a distinct object/table with an accurate example. (ii) [3] — [1] correct definition of one-to-many; [2] correct, case-study-specific example correctly explaining which side is 'one' and which is 'many' (e.g. SUPPLIER-PLANT or CUSTOMER-ORDERS). (b) [12]: [4] for the four blanks — [1] each for Blank A (CUSTOMER), Blank B (ORDER_LINE), Blank C (PLANT), Blank D (PLANT). [8] for the four relationships — [1] correct cardinality (one-to-many) + [1] valid case-study-grounded justification, for each of: CUSTOMER-ORDERS, ORDERS-ORDER_LINE, PLANT-ORDER_LINE, SUPPLIER-PLANT. A justification that only restates the cardinality without explaining why (e.g. 'because it's one to many') scores the cardinality mark only.

(a) A new order requires a row in ORDERS (holding the order-level data: OrderID, OrderDate, CustomerID) and a row in ORDER_LINE (holding the plant and quantity for that order), because Quantity depends on the combination of order and plant, not on the order alone:
INSERT INTO ORDERS (OrderID, OrderDate, CustomerID)
VALUES ('O2050', '2025-06-10', 'C12');

INSERT INTO ORDER_LINE (OrderID, PlantID, Quantity)
VALUES ('O2050', 'P07', 4);
Each statement names the target table and column list explicitly, followed by matching literal values in the same order (text values in quotes, the numeric Quantity unquoted). (b) The report requires joining PLANT to ORDER_LINE on the shared PlantID, grouping rows by plant so SUM() can total the Quantity for each plant, filtering grouped results with HAVING (not WHERE, since the filter is on an aggregated value), and sorting by the computed total:
SELECT PLANT.PlantName, SUM(ORDER_LINE.Quantity) AS TotalSold
FROM PLANT
JOIN ORDER_LINE ON PLANT.PlantID = ORDER_LINE.PlantID
GROUP BY PLANT.PlantID, PLANT.PlantName
HAVING SUM(ORDER_LINE.Quantity) > 10
ORDER BY TotalSold DESC;
This was self-verified by executing it against representative sample data (Lavender P07 with quantities 3, 5 and a new order of 4 sums to 12, correctly included as >10; Fern P15 with a single quantity of 1 correctly excluded as not >10), confirming the JOIN, GROUP BY, HAVING and ORDER BY clauses combine correctly to produce the required report. Answer: (a) two INSERT statements, one into ORDERS and one into ORDER_LINE, as shown; (b) the SELECT...JOIN...GROUP BY...HAVING...ORDER BY script shown above.

(a) [6]: first INSERT — [1] correct table (ORDERS) and column list, [1] correct values in matching order/type (OrderID and OrderDate and CustomerID as quoted text), [1] correct SQL INSERT syntax (INSERT INTO ... VALUES ...; terminated correctly). Second INSERT — [1] correct table (ORDER_LINE) and column list, [1] correct values (Quantity as an unquoted number), [1] correct SQL INSERT syntax. Award full credit for a single combined statement only if the candidate correctly recognises two separate INSERTs are needed (a single INSERT cannot correctly populate both tables). (b) [12]: [2] correct SELECT clause (PlantName and a SUM(Quantity) aggregate, sensibly aliased); [1] correct FROM clause; [3] correct JOIN clause (INNER JOIN or implicit join, correct ON condition PLANT.PlantID = ORDER_LINE.PlantID); [2] correct GROUP BY (by PlantID and/or PlantName, matching the non-aggregated SELECT column(s)); [2] correct HAVING clause filtering the aggregated SUM > 10 (WHERE used instead of HAVING to filter an aggregate scores 0 for this component); [2] correct ORDER BY ... DESC on the total. Accept table aliases, equivalent valid join syntax, and minor formatting variation; accept HAVING referencing the alias (e.g. HAVING TotalSold > 10) where the candidate's SQL dialect would support it.