2023 CCEA A-Level Software Systems Development CL4 Practice Paper with Answers

(a) User story: 'As a till operator, I want to see live stock levels at every branch, so that I never tell a customer an item is available when it has already been sold.' Fact-finding technique: Observation — watching till operators handle a real customer enquiry about stock at another branch would reveal exactly where the current paper-based process breaks down, which an interview alone might not surface.
(b) User story: 'As the Operations Director, I want an up-to-date report of profitability by product line across all stores, so that I can make stocking decisions without waiting for the weekly spreadsheet.' Fact-finding technique: Interview — a one-to-one interview with the Operations Director is the most efficient way to establish exactly which figures and time frame count as 'up to date' for a senior stakeholder's specific decision-making needs.
(c) User story: 'As a new till operator with little computer experience, I want simple, clearly labelled ordering screens, so that I can use the system correctly after a short induction.' Fact-finding technique: Questionnaire (or focus group) — surveying a sample of current till operators about which parts of existing systems they find confusing would gather usability requirements from many staff quickly, without needing to interview each one individually.
(d) User story: 'As the Finance Manager, I want the system to always use the current price stored in the database at the moment of sale, so that a customer cannot be charged an out-of-date price.' Fact-finding technique: Document analysis — examining existing price lists, price-change records and recent customer complaints about pricing would establish exactly how and when prices currently change, and where errors have occurred in the past.
Final answer: four correctly formatted user stories, each paired with a distinct, justified fact-finding technique (observation, interview, questionnaire/focus group, document analysis), 2 marks each, 8 marks total.

1 mark per row for a user story that correctly identifies the specific role, goal and benefit described in the scenario, in or close to the 'As a ___, I want ___, so that ___' format (accept minor rephrasing that preserves all three elements). 1 mark per row for naming a fact-finding technique (observation, interview, questionnaire, document analysis, focus group, or workshop) that is plausible for that specific requirement AND for a justification that refers to a genuine strength of that technique in this context (not a generic definition). Reject a fact-finding technique repeated with no attempt at a scenario-specific justification. Max 2 marks per row, 8 marks total. Accept any reasonable equivalent technique/justification not listed here if it is well justified for the specific stakeholder need.

(1) sequential — the Waterfall model is defined by moving through stages in a fixed, non-overlapping order. (2) Waterfall — the named traditional model referred to. (3) requirements — Waterfall assumes requirements are known and fixed from the outset. (4) documentation — each signed-off Waterfall stage produces formal documentation used as the basis for the next stage. (5) change — the well-known weakness of Waterfall is its difficulty accommodating changes once a stage has been signed off. (6) Agile — the umbrella term for iterative, flexible methodologies contrasted with Waterfall. (7) Scrum — a specific, named Agile framework using fixed-length development cycles. (8) sprint — the Scrum term for a short, fixed-length development cycle (commonly two to four weeks). (9) prototype — a working, testable version of the software that end users can try and give feedback on before the next cycle.
Final answer: sequential, Waterfall, requirements, documentation, change, Agile, Scrum, sprint, prototype (in that order).

1 mark for each of the 9 blanks correctly completed as shown in the solution. Accept only words/phrases from the given word bank; do not accept synonyms not listed, since this is a closed word-bank cloze exercise. Max 9 marks.

Throwaway prototyping involves building a quick, low-cost mock-up purely to explore or agree a requirement, with the prototype itself discarded once its purpose has been served and the real system built separately, often using different tools. This would be genuinely useful at GreenLeaf for resolving the stock-check screen design mentioned by till operators: a simple, disposable screen mock-up (even created in presentation software rather than the real development environment) could be shown to till staff at all four stores to agree exactly what information they need to see and how quickly, before any real database or programming work begins. Its usefulness lies in how cheaply and quickly it removes uncertainty about interface requirements, without risking wasted effort on production-quality code that might need to be substantially reworked.
Evolutionary prototyping, by contrast, involves building an initial working version of the real system and then incrementally refining that same version, cycle by cycle, into the final delivered product — nothing is thrown away. This would be genuinely useful for the core order-processing functionality itself: the team could deliver a first working version handling basic order entry and stock lookup at one pilot store, gather real feedback from actual use over several weeks, and then evolve that same system to add features such as the profitability reporting the Operations Director needs. Its usefulness lies in the fact that GreenLeaf staff may not be able to fully specify their needs (for example, exactly which profitability figures matter most) until they have used a working system in practice, and evolutionary prototyping allows those needs to be discovered and incorporated without discarding earlier, still-useful work.
Overall, both techniques are valuable at different points in the same project: throwaway prototyping suits GreenLeaf's need to resolve specific, high-uncertainty interface questions cheaply before committing resources, while evolutionary prototyping suits the ongoing development of the core system itself, allowing it to mature in response to genuine store-by-store feedback rather than upfront guesswork.

Levels of response (QWC assessed). Level 1 (1–2 marks): basic, general statements about prototyping with little or no distinction between throwaway and evolutionary prototyping, and no application to GreenLeaf; frequent errors in written expression may obscure meaning. Level 2 (3–4 marks): a clear distinction is made between throwaway and evolutionary prototyping, with at least one relevant example applied to the GreenLeaf case study; written expression is mostly clear, with a general sense of organisation and appropriate use of specialist terms. Level 3 (5–6 marks): a well-developed evaluation clearly distinguishing both types of prototyping, with specific, well-chosen examples applied convincingly to GreenLeaf for each type, and an overall judgement about when each is most useful; written expression is fluent, well organised and uses specialist terminology (e.g. 'evolutionary', 'disposable mock-up', 'iterative refinement') accurately throughout. Max 6 marks.

(a) Forward pass (EST/EFT), starting all activities with no predecessor at time 0: A has no predecessor, so EST(A)=0, EFT(A)=0+5=5. B's predecessor is A, so EST(B)=EFT(A)=5, EFT(B)=5+6=11. C's predecessor is A, so EST(C)=EFT(A)=5, EFT(C)=5+4=9. D's predecessor is B, so EST(D)=EFT(B)=11, EFT(D)=11+5=16. E's predecessors are C and D, so EST(E)=max(EFT(C), EFT(D))=max(9,16)=16, EFT(E)=16+8=24. F's predecessor is E, so EST(F)=EFT(E)=24, EFT(F)=24+4=28. G's predecessor is F, so EST(G)=EFT(F)=28, EFT(G)=28+3=31. The project duration is the largest EFT, which is EFT(G)=31 days.
Backward pass (LST/LFT), starting from the project end at day 31: G has no successor, so LFT(G)=31, LST(G)=31-3=28. F's only successor is G, so LFT(F)=LST(G)=28, LST(F)=28-4=24. E's only successor is F, so LFT(E)=LST(F)=24, LST(E)=24-8=16. D's only successor is E, so LFT(D)=LST(E)=16, LST(D)=16-5=11. C's only successor is E, so LFT(C)=LST(E)=16, LST(C)=16-4=12. B's only successor is D, so LFT(B)=LST(D)=11, LST(B)=11-6=5. A's successors are B and C, so LFT(A)=min(LST(B), LST(C))=min(5,12)=5, LST(A)=5-5=0.
Total float = LST − EST (equivalently LFT − EFT) for each activity: A: 0−0=0. B: 5−5=0. C: 12−5=7. D: 11−11=0. E: 16−16=0. F: 24−24=0. G: 28−28=0.
Full table: A (EST 0, EFT 5, LST 0, LFT 5, Float 0); B (EST 5, EFT 11, LST 5, LFT 11, Float 0); C (EST 5, EFT 9, LST 12, LFT 16, Float 7); D (EST 11, EFT 16, LST 11, LFT 16, Float 0); E (EST 16, EFT 24, LST 16, LFT 24, Float 0); F (EST 24, EFT 28, LST 24, LFT 28, Float 0); G (EST 28, EFT 31, LST 28, LFT 31, Float 0). [Verified independently by forward/backward pass recomputation in Python: identical results.]
(b) The critical path consists of every activity with zero total float, followed in sequence: A → B → D → E → F → G. Total project duration = 31 days.
(c) A Gantt chart alone shows each activity plotted against a timeline and can show planned versus actual progress clearly, but it does not explicitly show the logical dependency structure between activities (which activities must finish before others can start) in the way a network diagram does, and it does not calculate or display float directly. Relying on a Gantt chart alone, the Project Manager could see that activity C (GUI/screen design) is scheduled early, but would find it much less obvious that C has 7 days of float and could safely slip without delaying the project, whereas any slippage on A, B, D, E, F or G directly delays the 31-day completion date. A network diagram makes the critical path and float visible directly from the diagram's structure, which is valuable for deciding where close monitoring and contingency resource is genuinely needed.
Final answer: critical path A-B-D-E-F-G, total project duration 31 days, with C the only non-critical activity (float 7 days).

(a) 1 mark per activity for a correct EST/EFT pair (up to 7), plus 1 mark per activity for a correct LST/LFT pair and float value derived consistently from the candidate's own EST/EFT if forward-pass errors are carried through correctly (up to 7, capped at 10 marks total for part (a) with best-fit allocation across the two calculation stages) — award full method credit for a correct process even where an earlier arithmetic slip is carried forward consistently. (b) 1 mark for correctly identifying all and only the activities with zero float in the correct sequence (A-B-D-E-F-G); 1 mark for the correct total duration (31 days), which must be consistent with the candidate's own forward pass. (c) 1 mark for a valid point about what a network diagram shows that a Gantt chart does not (dependency logic and/or float); 1 mark for linking this specifically to the GreenLeaf schedule (e.g. identifying that only activity C has float); 1 mark for a reasoned evaluative comment on the risk of relying on a Gantt chart alone (e.g. harder to see which activities need close monitoring). Max 15 marks.

(a) A UML class box is divided into three horizontal compartments. The top compartment contains the class name. The middle compartment lists the class's attributes, each shown with its visibility symbol, name and data type (e.g. −customerName: String). The bottom compartment lists the class's methods (operations), each shown with its visibility symbol, name, any parameters, and its return type (e.g. +placeOrder(): void).
(b) Customer
−customerName: String
−customerPhone: String
+placeOrder(): void
(Written as three compartments: class name 'Customer'; attributes '−customerName: String' and '−customerPhone: String', both private as shown by the minus sign; method '+placeOrder(): void', public as shown by the plus sign, taking no parameters and returning nothing.)
(c) The Customer–Order association is one-to-many from Customer to Order: the multiplicity at the Customer end of the line is '1', meaning each Order is associated with exactly one Customer, and the multiplicity at the Order end is '1..' (or simply '' if zero is not meaningful here), meaning each Customer may be associated with one or many Orders. This correctly models the business rule that a customer can place many orders over time, but a single order cannot belong to more than one customer. The Order–Product relationship, by contrast, is many-to-many: a single order commonly contains several different products, and a single product (such as a popular compost bag) will appear on many different orders. UML class diagrams cannot represent a many-to-many relationship as a single direct association with simple multiplicities in the same way as a one-to-many relationship, because doing so would provide no way to record data that belongs to the specific combination of one order and one product, such as the quantity of that product ordered on that occasion, or the price charged at the time. An intermediate association class, OrderLine, resolves this by turning the single many-to-many relationship into two one-to-many relationships (one Order has many OrderLines; one Product appears on many OrderLines), with OrderLine itself holding attributes such as quantityOrdered that only make sense in the context of one specific order-product pairing.
(d) Producing a UML class diagram before building the database is valuable at GreenLeaf because it separates the conceptual question of what the data structure should be from the technical question of how to implement it in SQL, allowing the development team to review and agree the structure, relationships and cardinalities with stakeholders such as the Operations Director using a diagram that is far easier for a non-technical reader to understand than raw SQL statements. It also makes structural design errors, such as the need for an intermediate OrderLine class to resolve the many-to-many Order–Product relationship, visible and correctable at the design stage, where a mistake costs only a redrawn diagram, rather than being discovered only after CREATE TABLE statements, foreign keys and possibly real data already exist, where correcting the same mistake would require restructuring live tables. Going straight to SQL risks embedding this kind of structural error directly into the implemented database, where it is considerably more expensive and disruptive to fix. The main limitation is that producing a class diagram takes additional time upfront and does not itself guarantee correct SQL syntax, so it should be treated as a valuable complement to, rather than a replacement for, careful SQL implementation.

(a) 1 mark for each correctly described compartment (class name; attributes with type; methods with parameters/return type). Max 3. (b) 1 mark for correct class name; 1 mark for each correctly formatted attribute with correct visibility symbol and type (up to 2); 1 mark for the correctly formatted method with correct visibility symbol and return type. Max 4. (c) 1 mark for correct multiplicity at the Customer end ('1'); 1 mark for correct multiplicity at the Order end ('1..' or ''); 1 mark for correctly explaining what this means in terms of the business rule; up to 3 marks for a clear, accurate explanation of why an intermediate OrderLine class is needed (identifying the many-to-many relationship; explaining that it must be resolved into two one-to-many relationships; noting that OrderLine can hold pairing-specific attributes such as quantity). Max 6. (d) Levels of response (QWC assessed): Level 1 (1 mark): a basic, general statement of benefit with little development or GreenLeaf-specific detail; expression may be unclear. Level 2 (2–3 marks): a clear point about the value of modelling before implementation (e.g. easier to review with stakeholders, cheaper to fix errors), applied to the GreenLeaf case study, in reasonably clear written expression. Level 3 (4 marks): a well-developed evaluation making at least two distinct, well-explained points (e.g. stakeholder communication AND cost of late-discovered errors, such as the OrderLine case), applied specifically to GreenLeaf, in fluent, well-organised written expression using accurate specialist terminology. Max 4. Total for question: 17 marks.

(a) Test case table:
Test 1 — Test value: 50. Type of test data: Normal. Expected result: Value accepted; order proceeds with QtyOrdered = 50.
Test 2 — Test value: 1 (or 100). Type of test data: Boundary. Expected result: Value accepted, since 1 and 100 are the extreme valid limits of the accepted range.
Test 3 — Test value: 0 (or 101, or a non-numeric value such as 'abc'). Type of test data: Erroneous. Expected result: Value rejected; an error message is displayed and the order cannot proceed until a valid value (1–100) is entered.
(b) Black box testing treats the Order Management System as a 'black box': the tester provides inputs and checks whether the outputs match expected results, without any reference to, or knowledge of, the underlying program code. A specific example at GreenLeaf would be entering QtyOrdered = 150 on the order-entry screen and checking, purely from the user's point of view, that the system correctly displays an error message and refuses to accept the order — the tester does not need to know how the validation is coded, only whether the observable behaviour is correct. White box testing, by contrast, requires knowledge of the internal code structure and is designed to test the logic paths within the program itself, typically aiming for a target level of code coverage. A specific example at GreenLeaf would be a developer examining the actual validation code (for instance, an IF-ELSE statement checking QtyOrdered against the bounds 1 and 100) and deliberately constructing test data to ensure that both the 'valid' branch and the 'invalid' branch of that statement are each executed and checked at least once, confirming that every logical path through the validation code has actually been exercised, not just that the final displayed result looks correct from the outside.
Both forms of testing are complementary rather than alternatives: black box testing at GreenLeaf confirms the system behaves correctly from the till operator's point of view, while white box testing gives the development team confidence that the underlying validation logic itself has been exercised completely, including paths that might never be reached by a small, informal set of black box tests alone.

(a) 2 marks per row (up to 6): 1 mark for a valid, correctly typed test value (normal/boundary/erroneous as specified) matched consistently to the stated type, and 1 mark for a correct, specific expected result (accepted with correct behaviour, or rejected with an error message, as appropriate). Boundary values must be exactly 1 or 100 (or immediately adjacent invalid values 0/101 if offered as the erroneous case) to gain full credit; a vague expected result such as 'it works' with no detail should not gain the result mark. (b) Levels of response (QWC assessed): Level 1 (1–2 marks): basic, general description of black box and/or white box testing with little/no GreenLeaf-specific example; written expression may be unclear. Level 2 (3–4 marks): both black box and white box testing are described with a broadly relevant example for at least one, in clear written expression. Level 3 (5–6 marks): both black box and white box testing are clearly and accurately distinguished, each illustrated with a specific, well-explained GreenLeaf example (as in the solution), with a concluding point about how the two approaches complement each other; written expression is fluent and uses specialist terminology (e.g. 'code coverage', 'logic path') accurately. Max 6. Total for question: 12 marks.

Step 1 — First Normal Form (1NF): remove the repeating group {ProductCode, ProductDescription, UnitPrice, QtyOrdered} by giving each order-product combination its own row, and form a composite primary key from the order identifier and the product identifier (since neither alone uniquely identifies a row once the repeating group is flattened).
Order (OrderNo, OrderDate, CustomerID, CustomerName, CustomerPhone, StoreID, StoreName, ProductCode, ProductDescription, UnitPrice, QtyOrdered) — Primary key: (OrderNo, ProductCode).
Step 2 — Second Normal Form (2NF): remove partial dependencies, i.e. any non-key attribute that depends on only PART of the composite primary key rather than the whole key. OrderDate, CustomerID, CustomerName, CustomerPhone, StoreID and StoreName all depend only on OrderNo (they are the same regardless of which product is on the order), so they exhibit a partial dependency and must move to a table keyed on OrderNo alone. ProductDescription and UnitPrice depend only on ProductCode (they are the same regardless of which order the product appears on), so they exhibit a partial dependency and must move to a table keyed on ProductCode alone. QtyOrdered genuinely depends on the combination of both OrderNo and ProductCode (the quantity is specific to that product on that particular order), so it correctly remains in a table keyed on the full composite key.
Order (OrderNo, OrderDate, CustomerID, CustomerName, CustomerPhone, StoreID, StoreName) — Primary key: OrderNo.
OrderLine (OrderNo, ProductCode, QtyOrdered) — Primary key: (OrderNo, ProductCode).
Product (ProductCode, ProductDescription, UnitPrice) — Primary key: ProductCode.
Step 3 — Third Normal Form (3NF): remove transitive dependencies, i.e. any non-key attribute that depends on another non-key attribute rather than directly on the primary key. In the 2NF Order table, CustomerName and CustomerPhone depend on CustomerID (which is itself a non-key attribute of Order), not directly on OrderNo — a transitive dependency (OrderNo → CustomerID → CustomerName/CustomerPhone). Likewise, StoreName depends on StoreID, not directly on OrderNo — a transitive dependency (OrderNo → StoreID → StoreName). Both must be removed into their own tables.
Order (OrderNo, OrderDate, CustomerID, StoreID) — Primary key: OrderNo. Foreign keys: CustomerID references Customer(CustomerID); StoreID references Store(StoreID).
Customer (CustomerID, CustomerName, CustomerPhone) — Primary key: CustomerID.
Store (StoreID, StoreName) — Primary key: StoreID.
OrderLine (OrderNo, ProductCode, QtyOrdered) (unchanged) — Primary key: (OrderNo, ProductCode). Foreign keys: OrderNo references Order(OrderNo); ProductCode references Product(ProductCode).
Product (ProductCode, ProductDescription, UnitPrice) (unchanged) — Primary key: ProductCode.
Final answer: five 3NF tables — Order(OrderNo, OrderDate, CustomerID*, StoreID*), Customer(CustomerID, CustomerName, CustomerPhone), Store(StoreID, StoreName), OrderLine(OrderNo*, ProductCode*, QtyOrdered), Product(ProductCode, ProductDescription, UnitPrice) — where * marks a foreign key, each with no remaining partial or transitive dependencies.

1NF (2 marks): 1 mark for correctly flattening the repeating group into a single table with no nested groups; 1 mark for correctly identifying the composite primary key (OrderNo, ProductCode). 2NF (4 marks): 1 mark for correctly separating the Order attributes (dependent only on OrderNo); 1 mark for correctly separating the Product attributes (dependent only on ProductCode); 1 mark for correctly retaining QtyOrdered in a link/OrderLine table keyed on the full composite key; 1 mark for correctly stated primary keys on all three 2NF tables. 3NF (5 marks): 1 mark for correctly identifying and removing the CustomerName/CustomerPhone transitive dependency into a Customer table; 1 mark for correctly identifying and removing the StoreName transitive dependency into a Store table; 1 mark for the resulting Order table correctly reduced to (OrderNo, OrderDate, CustomerID, StoreID) with OrderNo as primary key; 1 mark for correctly identifying CustomerID and StoreID as foreign keys in the Order table; 1 mark for correctly labelling OrderLine and Product as unchanged from 2NF with their keys/foreign keys correctly stated. Max 11 marks. Award full marks for a candidate's own consistent table/attribute naming provided the underlying structure and dependency reasoning is correct.

(a) CREATE TABLE Product (
ProductCode CHAR(6) NOT NULL,
ProductDescription VARCHAR(60) NOT NULL,
UnitPrice DECIMAL(7,2) NOT NULL,
PRIMARY KEY (ProductCode),
CONSTRAINT chk_UnitPrice CHECK (UnitPrice > 0)
);
CHAR(6) gives ProductCode a fixed 6-character length as specified; NOT NULL on ProductDescription and UnitPrice ensures neither can be left blank; VARCHAR(60) allows description text up to 60 characters; DECIMAL(7,2) stores currency to exactly 2 decimal places; the CHECK constraint enforces UnitPrice > 0; PRIMARY KEY (ProductCode) both uniquely identifies each row and, in most RDBMSs, automatically enforces NOT NULL and uniqueness on ProductCode.
(b) SELECT c.CustomerName, s.StoreName, o.OrderDate
FROM Customer c
JOIN Order o ON c.CustomerID = o.CustomerID
JOIN Store s ON o.StoreID = s.StoreID
JOIN OrderLine ol ON o.OrderNo = ol.OrderNo
JOIN Product p ON ol.ProductCode = p.ProductCode
WHERE p.ProductDescription = '20L Multi-Purpose Compost'
ORDER BY o.OrderDate;
This query joins across all five tables of the 3NF schema, following the foreign-key chain from Customer through Order and OrderLine to Product, so that the WHERE clause can filter on the product description while still returning the customer name and store name held in the other tables; ORDER BY o.OrderDate satisfies the requirement to list results by order date.
(c) SELECT p.ProductCode, p.ProductDescription, SUM(ol.QtyOrdered) AS TotalQty, SUM(ol.QtyOrdered * p.UnitPrice) AS TotalValue
FROM Product p
JOIN OrderLine ol ON p.ProductCode = ol.ProductCode
GROUP BY p.ProductCode, p.ProductDescription
HAVING SUM(ol.QtyOrdered * p.UnitPrice) > 100
ORDER BY TotalValue DESC;
GROUP BY p.ProductCode, p.ProductDescription aggregates all order-line rows for the same product into a single summary row; SUM(ol.QtyOrdered) gives the total quantity ordered for that product across every order; SUM(ol.QtyOrdered * p.UnitPrice) gives the total monetary value of all orders for that product. HAVING (not WHERE) is required here because the filter condition (total value > £100) applies to the aggregated SUM, not to an individual row, and WHERE is evaluated before aggregation while HAVING is evaluated after it. ORDER BY TotalValue DESC satisfies the requirement to list the highest-value products first.
Worked check of the logic on the example order (OrderNo 1042): the greenhouse line contributes QtyOrdered 1 × UnitPrice 249.99 = £249.99 to its product's TotalValue, and the compost line contributes QtyOrdered 6 × UnitPrice 8.50 = £51.00 to its product's TotalValue; both figures are computed by exactly the SUM(ol.QtyOrdered * p.UnitPrice) expression in the query, confirming the arithmetic logic is correctly expressed in SQL (6 × 8.50 = 51.00 and 1 × 249.99 = 249.99, verified by direct multiplication).

(a) 1 mark for CREATE TABLE Product syntax with correct column list structure; 1 mark for ProductCode CHAR(6); 1 mark for ProductDescription VARCHAR(≤60) with NOT NULL; 1 mark for UnitPrice as a 2-decimal-place numeric/decimal type with NOT NULL; 1 mark for a CHECK constraint enforcing UnitPrice > 0; 1 mark for correctly declared PRIMARY KEY (ProductCode). Max 6. (b) 1 mark for correct SELECT column list; 1 mark per correct JOIN condition on the correct foreign-key relationship (up to 4 joins); 1 mark for a correct WHERE clause filtering on the specified product; 1 mark for correct ORDER BY o.OrderDate; 1 mark for overall correct, executable SQL syntax (commas, aliases, terminating semicolon). Max 8 (accept full marks for any logically equivalent join order/syntax that returns the correct result set). (c) 1 mark for correct SELECT list including both SUM aggregates with sensible aliases; 1 mark for correct JOIN between Product and OrderLine; 1 mark for correct GROUP BY including all non-aggregated selected columns; 1 mark for correct SUM(ol.QtyOrdered); 1 mark for correct SUM(ol.QtyOrdered * p.UnitPrice); 1 mark for using HAVING (not WHERE) to filter on the aggregate; 1 mark for the correct threshold condition (> 100); 1 mark for correct ORDER BY TotalValue DESC. Max 8. Total for question: 22 marks.