How do I revise Programmed Solution to a Problem for WJEC A-Level?

Ensure the chosen problem has sufficient scope to access the full range of marks

What exam tips are there for Programmed Solution to a Problem? (2)

Use appropriate subject-based technical vocabulary throughout the investigation report

What exam tips are there for Programmed Solution to a Problem? (3)

Clearly link the investigation findings to the proposed project objectives

What mistakes should I avoid in Programmed Solution to a Problem?

Failing to identify all relevant stakeholders

What are common errors in Programmed Solution to a Problem exams? (2)

Providing superficial analysis of current system limitations

Programmed Solution to a Problem

WJEC

A-Level

The investigation phase of the Component 3 non-exam assessment requires candidates to conduct a thorough analysis of a chosen problem to identify stakeholder requirements and system limitations. Candidates must research existing solutions, analyze current data flows and processing, and produce a formal working specification with measurable success criteria.

Objectives

Exam Tips

Pitfalls

Key Terms

Mark Points

Subtopics in this area

Programmed Solution to a Problem

Topic Overview

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.

What You Need to Demonstrate

Key skills and knowledge for this topic

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

Marking Points

Key points examiners look for in your answers

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
Identification of a substantial problem with sufficient scope for A-level assessment
Clear description of broad project aims using appropriate technical vocabulary
Detailed identification and description of potential limitations of the proposed solution
Evidence of considering and incorporating feedback from teachers and peers to refine the project understanding
Breakdown of the problem into sub-problems with clear links to project objectives
Detailed specification of input and output layouts, reports, and forms
Design and documentation of data structures and access methods
Definition of validation routines for all data entry
Identification of all necessary processing routines
Documentation of processing routines using a structured convention such as pseudo-code
Clear demonstration of the interconnection between programs and data files
Justification of the choice of areas included in the prototype and reasons for omitting others
Creation of a comprehensive range of screens and outputs for the chosen areas
Functioning system that carries out all chosen processes using realistic data
Evaluation of the prototype's functioning and justification of its good features
Description of shortcomings and specific suggestions for improvement
Obtaining feedback from a competent third party
Describing feedback received and explaining its implications for system re-design
Re-structuring input and output facilities based on feedback
Updating files and data structures to accommodate additional data requirements
Describing new relationships between data and processes in the revised design
Documenting all processing routines using a recognised convention
Providing justification for any feedback suggestions that were discounted
Refinement of prototype based on feedback and amended design documentation
Production of a functional, finished system suitable for audience and purpose
Production of annotated listings to facilitate future maintenance
Effective use of programming facilities and tools
Well-structured, modular code with appropriate use of local and global variables
Use of complex user-defined routines and effective validation/exception handling
Documentation of variables and data structures
Evidence of a completed user interface
Evidence of developmental testing at each stage of the solution's creation
Evidence of problems encountered during development and the actions taken to overcome them
A comprehensive test plan covering all system functions
Use of a wide range of testing methods
Use of test data including typical, extreme, and invalid data
Annotated test runs with detailed commentaries on outcomes
Specific suggestions for system refinement based on testing results
Detailed evaluation of the effectiveness of the programming language used
Justification of tools and techniques employed during development
Comparison of the completed system with similar commercially available systems
Identification of successful features and specific suggestions for improving less successful areas
Critical description of personal strengths and weaknesses in design and prototyping
Description of alternative approaches that would be adopted for similar future problems

Examiner Tips

Expert advice for maximising your marks

💡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
💡Ensure the chosen problem is substantial enough to allow for the full range of marks across all assessment criteria
💡Maintain a clear record of all discussions and feedback sessions with teachers and peers
💡Use technical language consistently when describing aims and limitations
💡Be prepared to justify why certain feedback was or was not incorporated into the final project plan
💡Ensure all designs are documented using a recognised, consistent convention
💡Explicitly link every design element back to the project objectives identified in the investigation phase
💡Use clear, self-documenting identifiers in your design documentation
💡Ensure the design is detailed enough that a third party could implement the system without further clarification
💡Review the design against the specification to ensure all requirements are covered
💡Ensure the prototype is a working subset of the final system, not just a series of static screenshots.
💡Use realistic data that reflects the actual requirements of the problem to demonstrate functionality.
💡Clearly document the evaluation of the prototype, as this is essential for justifying the subsequent refinement of the design.
💡Discuss the prototype in technical terms with teachers and peers to gather feedback for the next stage.
💡Ensure the feedback is from a 'competent third party' rather than just a peer who lacks technical understanding
💡Maintain a clear audit trail between the prototype evaluation, the feedback received, and the resulting design changes
💡Ensure all revised design documentation is detailed enough for a third party to implement the changes
💡Use formal, recognised conventions (e.g., pseudo-code) for all revised processing routines
💡Ensure the code is fully self-documenting with clear identifiers
💡Use modular programming techniques to improve maintainability
💡Ensure the final system is fully functional and tested against the original success criteria
💡Maintain clear, annotated listings that a third party could follow
💡Ensure the user interface is fit for purpose and matches the design documentation
💡Ensure test data is realistic and covers all possible input scenarios, including boundary values
💡Document every error found during development, even if it seems minor, and explain how it was resolved
💡Use a structured test plan table that maps functions to test data and expected outcomes
💡Ensure all test runs are annotated to explain what is happening and why the result is correct or incorrect
💡Use the testing phase to inform the final evaluation of the system's success
💡Ensure the evaluation is well-structured and clearly expressed
💡Use specialist technical terms with ease and accuracy
💡Ensure the review is error-free and professional in tone
💡Explicitly link the evaluation of the programming language to the specific tools and techniques used in the project
💡Be honest and specific about personal performance rather than providing generic statements

Common Mistakes

Pitfalls to avoid in your exam answers

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
Choosing a problem that is too trivial or lacks sufficient complexity for A-level
Failing to document the feedback received from peers and teachers
Neglecting to identify or describe the limitations of the proposed solution
Using vague language instead of appropriate subject-based technical vocabulary
Failing to justify the breakdown of the problem into sub-problems
Incomplete documentation of data structures or access methods
Lack of detail in pseudo-code, making it impossible for a third party to implement
Insufficient validation routines for data entry
Poorly defined relationships between data and processing routines
Failing to use realistic data for output and storage
Omitting the justification for why certain areas were included or excluded from the prototype
Neglecting to evaluate the prototype's performance or identify its shortcomings
Producing static mock-ups instead of a functioning system that carries out processes
Failing to document the feedback received from third parties
Neglecting to update the original design documentation to reflect changes made after prototyping
Failing to justify why certain feedback suggestions were not implemented
Using informal or non-standard conventions for documenting revised processing routines
Failure to refine the prototype based on feedback
Inadequate annotation of code listings
Poor modularity or over-reliance on global variables
Lack of validation or exception handling routines
System not meeting the objectives set out in the initial specification
Failing to include evidence of testing at each stage of development
Using only typical data and omitting extreme or invalid test cases
Lack of detailed commentary or justification for the actions taken to fix errors
Incomplete test plans that do not cover all system functions
Failure to provide annotated test runs that link back to the test plan
Providing a superficial description of the programming language rather than an evaluation of its effectiveness
Failing to make a meaningful comparison with commercial systems
Lack of specific, actionable suggestions for system improvement
Vague self-reflection that does not identify specific strengths or weaknesses in performance
Failure to use specialist technical vocabulary accurately

Frequently Asked Questions

Common questions students ask about this topic

Likely Command Words

How questions on this topic are typically asked

Describe

Identify

Analyse

Justify

Explain

Produce

Consider

Refine

Specify

Design

Document

Create

Evaluate

Make

Obtain

Demonstrate

Select

Dry-run

Apply

Compare

Contrast

Ready to test yourself?

Practice questions tailored to this topic

Programmed Solution to a Problem

Subtopics in this area

Topic Overview

What You Need to Demonstrate

Marking Points

Examiner Tips

Common Mistakes

Frequently Asked Questions

Likely Command Words

Ready to test yourself?

Related Topics in WJEC A-Level Computer Science

Programming and System Development

Computer Architecture, Data, Communication and Applications

Computer Architecture, Data, Communication and Applications

Programming and System Development

Programmed Solution to a Problem

Subtopics in this area

Topic Overview

What You Need to Demonstrate

Marking Points

Examiner Tips

Common Mistakes

Frequently Asked Questions

What is the difference between validation and verification in programming?

How do I choose a good problem for my A-Level Computer Science NEA?

What should be included in the design section of my NEA report?

How do I write a good evaluation for my programming project?

What is the difference between black-box and white-box testing?

How can I make my code more efficient in a programmed solution?

Likely Command Words

Ready to test yourself?

Related Topics in WJEC A-Level Computer Science

Programming and System Development

Computer Architecture, Data, Communication and Applications

Computer Architecture, Data, Communication and Applications

Programming and System Development