Non-exam assessment - the computing practical project — AQA A-Level Computer Science

The non-exam assessment (NEA) for AQA A-Level Computer Science is a substantial programming project that accounts for 20% of your final grade. You must develop a complete software solution to a problem of your choice, applying the systematic approach of analysis, design, implementation, testing, and evaluation. This project is your opportunity to demonstrate creativity, technical skill, and the ability to manage a complex task independently. It mirrors real-world software development, where you identify a user's needs, design a solution, write code, and reflect on your work.

The NEA is divided into five sections: Analysis, Design, Implementation, Testing, and Evaluation. In Analysis, you define the problem, identify stakeholders, and gather requirements. Design involves planning the system architecture, algorithms, data structures, and user interface. Implementation is where you write the code, using a programming language of your choice (e.g., Python, Java, C#). Testing requires you to create a test plan, execute tests, and fix bugs. Finally, Evaluation asks you to assess your solution against the original requirements and suggest improvements. Each section is equally important; examiners look for a clear, logical progression and evidence of refinement.

This project is not just about coding; it's about the entire development lifecycle. You must show that you can think like a software engineer: breaking down a problem, designing a solution, and justifying your decisions. The NEA also prepares you for university or industry, where project management and documentation are key. To succeed, choose a problem that genuinely interests you and is complex enough to demonstrate high-level skills, such as using databases, APIs, or advanced algorithms. Avoid over-ambitious projects; a well-executed moderate project scores higher than a poorly finished complex one.

• →Systematic approach: Follow the project lifecycle (Analysis, Design, Implementation, Testing, Evaluation) in order, but be prepared to iterate as you refine your solution.
• →Requirements specification: Clearly define functional and non-functional requirements, using techniques like user stories, use cases, or MoSCoW prioritisation.
• →Algorithm design and data structures: Plan efficient algorithms (e.g., sorting, searching) and choose appropriate data structures (e.g., arrays, lists, dictionaries, trees) to solve the problem.
• →Testing methodology: Create a comprehensive test plan covering normal, boundary, and erroneous data. Use black-box and white-box testing, and document test results with screenshots.
• →Evaluation against objectives: Assess your solution against the original success criteria, discussing strengths, weaknesses, and potential improvements. Reflect on the development process and lessons learned.

• Analysis (9 marks): Scoping, requirements documentation, and measurable specific objectives.
• Documented design (12 marks): Articulation of the solution structure and reliance on external libraries or frameworks.
• Technical solution (42 marks): Completeness of the solution and demonstration of technical skills (algorithms, data models, coding style).
• Testing (8 marks): Evidence of thorough testing using representative samples (normal, boundary, erroneous data).
• Evaluation (4 marks): Assessment of how well the outcome meets requirements, independent feedback, and discussion of potential improvements.

• 💡Start prototyping and writing code early in the project process.
• 💡Tackle the critical path of the project first to ensure a working system.
• 💡Ensure the project documentation is concise and presented in the order specified by the mark scheme.
• 💡Use a best-fit approach when assigning levels in the mark scheme.
• 💡Ensure the problem chosen is sufficiently different from other students in the centre to avoid malpractice.
• 💡Document everything as you go. Keep a development log with screenshots of early versions, bugs, and changes. This shows the evolution of your project and can be used in your evaluation.
• 💡Choose a project that allows you to demonstrate a range of skills, such as file handling, database connectivity, or use of external libraries. Avoid projects that are purely console-based or too simple.
• 💡In the evaluation, be honest about limitations. Examiners reward critical reflection. If something didn't work, explain why and how you would fix it. This shows maturity and understanding.

• Choosing a project that is not of A-level standard, leading to restricted marks.
• Failing to provide clear evidence of testing or using non-representative samples.
• Lack of independent feedback in the evaluation section.
• Poorly structured code that lacks annotation or meaningful identifiers.
• Treating the project as a linear process rather than an iterative one.
• Mistake: Starting implementation without a detailed design. Correction: Spend time on design; it saves time later. Use structure charts, flowcharts, or pseudocode to plan before coding.
• Mistake: Testing only with 'normal' data. Correction: Include boundary and invalid data tests. For example, if input expects a number between 1 and 10, test with 0, 1, 10, 11, and letters.
• Mistake: Writing evaluation that is too brief or generic. Correction: Be specific. Compare your solution to the original requirements, mention what you would change, and justify why.