An overview of the A2 2 Application Development case study: analysing a set scenario, designing, building, testing and evaluating an application, and documenting the development to the CCEA assessment criteria.

What this unit is

A2 2 Application Development is the coursework unit of CCEA A-Level Digital Technology. Rather than a written exam, it is a case study based piece of work: CCEA sets a scenario, and you develop a working application for it under controlled conditions, documenting your analysis, design, development, testing and evaluation to the assessment criteria. It puts the AS 1 systems-development theory and the A2 1 database and application knowledge into practice on a single, sustained project.

The shape of the case study

Because the requirements come from a set scenario, the first task is to read it closely and identify the end user, the problem, and the functional and non-functional requirements. Everything that follows, design, build, testing, must trace back to those requirements.

Analysis and design

In analysis you separate what the application must do (functional requirements such as recording a booking) from qualities and constraints (non-functional requirements such as usability and validation), and you identify the inputs, outputs, processing and data storage. In design you turn those requirements into a blueprint: 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. Strong work justifies each design decision against a requirement, so nothing is designed that the scenario does not need.

Implementation, testing and evaluation

In implementation you build the application from the design, applying validation and good interface practice. In testing you work from a test plan derived from the requirements, using normal, boundary and erroneous test data, recording actual results with evidence (such as annotated screenshots) and fixing then retesting any defects. In evaluation you judge the finished application against the original requirements, stating what was and was not met, reflecting on strengths and weaknesses, using any user feedback, and suggesting realistic improvements.

How to approach it

Treat the case study as a disciplined application of everything in the course. Plan your time across the stages, keep documentation as you go rather than at the end, and make sure every artefact, design, code, test, evaluation, links clearly back to the scenario's requirements. Always work from the current CCEA specification, the set case study brief and the assessment criteria issued for your series, because the exact scenario and weighting are set by CCEA and change between series.

Try this

Q1. State the first stage of the case study, before any design or coding. [1 mark]

• Cue. Analysis: reading the scenario to identify the end user and the requirements.

Q2. Name the three kinds of test data you should use when testing the application. [3 marks]

• Cue. Normal (valid), boundary (edge-of-range) and erroneous (invalid) test data.

Q3. Explain why the evaluation should refer back to the original requirements. [2 marks]

• Cue. The application is judged by whether it solved the set problem, so evaluating against the original requirements (with test evidence) shows objectively which were met and which were not.