Programmed Solution to a Problem — Eduqas A-Level Computer Science

A programmed solution to a problem is the process of designing, writing, testing, and implementing a computer program to solve a specific real-world or theoretical problem. In the WJEC A-Level Computer Science specification, this topic is central to the coursework component (Non-Exam Assessment) and also appears in the written exams, where students must demonstrate an understanding of the systematic approach to problem-solving. The topic covers the full development lifecycle, from initial problem definition and requirements analysis through to design, coding, testing, and evaluation. It emphasises the importance of a structured methodology, such as the waterfall model or agile approaches, and requires students to apply computational thinking skills—decomposition, pattern recognition, abstraction, and algorithm design—to break down complex problems into manageable steps.

Mastering this topic is crucial because it forms the backbone of practical programming and software development. Beyond the exam, the ability to create a programmed solution is a fundamental skill in computer science, enabling students to automate tasks, analyse data, and build applications. In the WJEC A-Level, students are expected to produce a substantial piece of code (often in Python, Java, or C#) that solves a problem of their choice, accompanied by a written report documenting the process. This mirrors real-world software engineering practices and prepares students for further study or careers in technology. The topic also reinforces key concepts such as data structures, algorithms, and user interface design, making it a unifying theme across the entire specification.

Understanding how to approach a programmed solution systematically is not just about writing code; it involves critical thinking, planning, and reflection. Students learn to identify success criteria, choose appropriate algorithms, handle errors gracefully, and test thoroughly. The evaluation phase requires them to consider efficiency, usability, and maintainability—skills that are highly valued in industry. By the end of this topic, students should be able to independently manage a project from inception to completion, documenting each stage clearly and justifying their decisions.

• →The problem-solving lifecycle: analysis, design, implementation, testing, and evaluation. Each stage has specific deliverables, such as a requirements specification, algorithm designs (flowcharts or pseudocode), annotated code, test plans, and a critical evaluation.
• →Computational thinking: decomposition (breaking the problem into smaller parts), pattern recognition (identifying similarities with known problems), abstraction (focusing on essential details), and algorithm design (creating step-by-step solutions).
• →Validation and verification: validation checks that input data is sensible (e.g., range checks, type checks), while verification ensures the program meets its requirements (e.g., through testing against test cases). Both are essential for robust solutions.
• →Testing strategies: black-box testing (based on specifications, ignoring internal code) and white-box testing (examining code paths). Students must create a test plan covering normal, boundary, and erroneous data, and document results.
• →Documentation: technical documentation (for developers, including code comments and variable lists) and user documentation (for end-users, including installation guides and help screens). Both are required in the NEA report.

• Use of a range of appropriate methods to investigate the existing system
• Thorough investigation of the current system
• Extensive desk-based research into existing solutions to similar problems
• Identification and description of all stakeholders and their requirements
• Detailed analysis of data collected for input and processing
• Consideration and explanation of all current system outputs and limitations
• Production of a working specification summarizing project purpose
• Technical justification of methods to be used in the solution
• Setting of objectives including measurable success criteria

• 💡Ensure the chosen problem has sufficient scope to access the full range of marks
• 💡Use appropriate subject-based technical vocabulary throughout the investigation report
• 💡Clearly link the investigation findings to the proposed project objectives
• 💡Document all investigation methods used to provide evidence for the moderator
• 💡Ensure the working specification is precise and clearly defines the required performance
• 💡In the NEA, ensure your problem is well-defined and scoped appropriately. A problem that is too simple will not allow you to demonstrate higher-level skills, while one that is too complex may be impossible to complete. Aim for a problem that requires at least one complex data structure (e.g., a dictionary, list of objects) and a non-trivial algorithm (e.g., sorting, searching, or recursion).
• 💡When writing algorithms in exams, use clear, unambiguous pseudocode that matches the style taught in class. Avoid programming-language-specific syntax unless explicitly allowed. Show intermediate steps and consider edge cases—examiners reward thoroughness.
• 💡For testing, always include a test plan with expected results and actual results. Use a table format and include at least one test for normal, boundary, and erroneous data. In the evaluation, discuss any discrepancies and how they were resolved.

• Failing to identify all relevant stakeholders
• Providing superficial analysis of current system limitations
• Setting vague objectives that lack measurable success criteria
• Insufficient research into existing solutions to similar problems
• Lack of technical justification for the chosen methods
• Misconception: 'Testing only needs to be done at the end of development.' Correction: Testing should be iterative—unit testing during implementation, integration testing as modules are combined, and system testing at the end. Early testing catches bugs sooner and reduces rework.
• Misconception: 'Pseudocode and flowcharts are optional or can be skipped.' Correction: In the WJEC A-Level, design documentation (including algorithms) is a mandatory part of the NEA and exam questions. They demonstrate logical thinking and are often worth significant marks.
• Misconception: 'The evaluation is just a summary of what went wrong.' Correction: Evaluation should critically assess the solution against success criteria, discuss limitations, suggest improvements, and reflect on the development process. It is not just a list of bugs.