CCEA A-Level Digital Technology A2 2 Application Development (Case Study): a complete overview of the coursework unit

What this unit demands

A2 2 Application Development is the practical, coursework half of A2 Digital Technology. CCEA sets a case study scenario, and you develop a working application for it under controlled conditions, documenting every stage to the assessment criteria. It is where the systems-development theory of AS 1 and the database and application knowledge of A2 1 are applied to one real, sustained project. Because it is assessed by your documented process as well as the product, planning and clear documentation matter as much as coding skill.

This guide explains how to approach each stage; the dot-point page gives a worked walkthrough and practice questions.

Analysis: start from the scenario

The case study sets the requirements, so read it closely. Identify the end user, the problem to solve, and the requirements, separating functional requirements (what the application must do) from non-functional ones (usability, performance, validation, security). List the inputs, outputs, processing and data storage the application needs, and note any constraints the scenario states. Everything later must trace back to this analysis.

Design: a blueprint that meets the requirements

From the requirements, design the data structure (tables or files, fields and a data dictionary), the user interface (screen layouts and navigation), the processing (algorithms and validation rules) and the test plan. Justify each decision against a requirement, so nothing is designed that the scenario does not need, and every requirement is covered by part of the design.

Implementation and testing

Build the application from the design, applying validation and good interface practice. Then test from a test plan derived from the requirements, using normal, boundary and erroneous test data, recording actual results with evidence (annotated screenshots), and logging, fixing and retesting defects. Testing the edges and invalid inputs, not just the happy path, is what catches real faults.

Evaluation

Judge the finished application against the original requirements: state what was and was not met, and how well, using the test results and any user feedback. Reflect on strengths and weaknesses and suggest realistic improvements. An evidence-based evaluation tied to the scenario is what demonstrates the problem was solved.

How this unit is assessed

A2 2 is assessed on your documented process and the finished application against CCEA's criteria, under controlled conditions, rather than by a written paper.

• Analysis. Requirements drawn clearly from the scenario.
• Design. Data, interface, processing and tests, justified against requirements.
• Implementation. A working application built from the design.
• Testing. Planned, evidenced tests with appropriate data.
• Evaluation. Requirement-by-requirement, evidence-based, with improvements.

Check your knowledge

A mix of process and best-practice questions covering the unit. Use these to check your understanding of the development process the case study assesses.

1. Name the first stage of the development process, before design. (1 mark)
2. Distinguish between a functional and a non-functional requirement. (2 marks)
3. List four things a design should specify. (2 marks)
4. Name the three kinds of test data you should use. (3 marks)
5. State what a test plan should record for each test. (2 marks)
6. Explain why the evaluation should refer to the original requirements. (2 marks)
7. Give one reason documentation should be kept as you go rather than at the end. (1 mark)
8. State one common mistake that loses marks in the case study. (1 mark)