Non-Exam Assessment (NEA) (AQA A-Level Computer Science): Revision Notes

Non-Exam Assessment (NEA)

Introduction to the NEA

The non-exam assessment is a substantial practical project that forms a significant part of your A-level Computer Science qualification. This coursework component is worth 20% of your total A-level grade, making it essential to approach it carefully and systematically.

You'll need to work through the complete stages of system development to produce a programmed solution to a chosen problem or investigation. This is a major undertaking that should take at least 50 hours to complete, with the majority of marks awarded for your technical solution. The project requires you to demonstrate your programming skills, analytical thinking, and ability to document your work professionally.

Understanding the agile approach

When working on your NEA, you should be familiar with the agile approach to software development. This modern methodology recognises that software projects rarely follow a perfectly linear path from start to finish. Instead, the agile approach embraces flexibility and continuous improvement.

The key characteristics of agile development that apply to your project include:

• Adaptive planning: Your initial plans may need to change as you progress through the development stages. This is completely normal and expected.

• Evolving development: As you create your technical solution, you may discover better ways to implement features or need to adjust your approach after creating a prototype.

• Early completion: You should aim to finish your technical solution ahead of schedule. This allows time for making necessary changes and improvements.

• Continuous improvement: Maintain a mindset of constantly refining your work. You may need to add to or modify aspects of your code as you develop a deeper understanding of the problem.

Mark allocation

Understanding how marks are distributed across your project will help you prioritise your efforts effectively. The total of 75 marks is divided across five main sections:

Section	Marks
Analysis	9
Documented design	12
Technical solution	42
Testing	8
Evaluation	4
Total	75

Selecting a project

Two main options

You have two pathways when choosing your NEA project:

Option 1: Solving a real problem

You can identify a genuine problem faced by a real end user and create a system that allows interaction with the user. Your solution should involve the storage, manipulation, and output of data. You must have an actual user (not just yourself) who has a real need for the system.

Option 2: Investigating a computing aspect

Alternatively, you can investigate a specific area of computer science, such as artificial intelligence or 3D graphical modelling. This path requires you to work with a project supervisor who will guide your investigation.

Finding project ideas

Start by exploring areas that interest you personally and where you already have some knowledge or connection. Consider these sources:

Family and friends: Ask whether there's anything they do in their work or hobbies that could form the basis of a project. For example, you might develop a system related to their profession.

Work experience placements: If you've had work experience, particularly if you maintain contact with the organisation, this can provide excellent project opportunities based on real business needs.

Personal hobbies and interests: Your own interests in gaming, social media, clubs, or societies you're involved in can inspire project ideas. Systems related to activities you're passionate about often result in more motivated and successful work.

Available tools and skills: Base your choice on the programming languages and tools available in your school or college. For example, if you've been learning Visual Basic or Python throughout your course, you'll likely find more support for projects using these languages. Consider your level of expertise with different software packages when making your decision.

Example project ideas

Here are some possibilities to inspire your thinking (this isn't an exhaustive list):

• Simulating a business or scientific issue (such as modelling share prices or flu epidemics)
• Investigating well-known problems (such as the game of life, Towers of Hanoi, or the travelling salesman problem)
• Creating data processing solutions for organisations (membership systems for clubs or gyms, booking systems for holiday companies or medical appointments, stock control systems, student timetabling and school reporting systems)
• Developing optimisation solutions (production rotas, shortest-path problems, route finding)
• Building a computer game
• Exploring artificial intelligence applications or investigating machine learning algorithms
• Creating control systems operated using devices like Arduino boards, Raspberry Pi, or robotic arms
• Developing websites with dynamic content driven by database back-ends (note that static websites aren't sufficient for A-level)
• Rendering three-dimensional worlds on screen
• Creating mobile phone or tablet apps of suitable complexity
• Exploring large datasets and visualising correlations

Analysis section (9 marks)

The analysis stage is often considered the most challenging part of the project because it requires identifying and working with a real user or project supervisor. If your user has a genuine problem that needs solving, they'll provide much of the information you need, making this section easier.

What to include in your analysis

Your analysis should demonstrate thorough research and understanding of the problem. Include the following components:

Background information: Provide general context about the organisation or person you're creating the system for. Make sure this is sufficient for a third party to read and understand without needing additional explanation.

Problem description: Write a clear statement that describes the problem area and the specific issue being solved or investigated. This should be focused and precise.

Critical path analysis: Analyse the project's critical path in terms of identifying the main stages and the sequence in which they should be completed. Show the dependencies between stages.

Research evidence: Outline how you researched the problem. This might include interviews or questionnaires with the user or supervisor, source documents from any current system, or evidence of research into the chosen computing aspect. Include observation notes of the existing system where relevant.

User requirements: List what the user requires from the system, including any limitations or constraints.

Objectives: Document general and specific objectives that are realistic, achievable, and measurable. These will be crucial for your evaluation later.

Modelling: Include any modelling that helps inform the design stage. This could include graph models, entity-relationship models, or data flow diagrams.

Assessment criteria for analysis

Your analysis will be marked according to four main criteria:

• How well you've scoped the problem and explained it in an easy-to-understand way
• Whether you've created a fully documented set of measurable and appropriate specific objectives
• Whether the requirements were identified through proper research and dialogue with the user
• Whether the problem has been sufficiently well modelled to be useful in subsequent stages

Design section (12 marks)

The design stage bridges the gap between understanding the problem and implementing the solution. AQA doesn't require you to produce full designs of every button, form, or report. Instead, they want to see evidence of design for the 'key aspects' - the important elements that a third party would need to understand.

What to include in your design

Your design documentation will typically combine written explanations with diagrams. Include these elements:

Overall system design: Present the structure of your system, perhaps using a top-down design diagram, system flowchart, or entity-relationship model.

Module descriptions: Describe the main modules that will make up the system.

Data items: Document the data structures you'll use, including data types.

File structures: Describe how you'll organise files in your system.

Algorithm explanations: Outline the main algorithms you'll implement. It may be appropriate to use pseudo-code or specific programming code (for example, SQL queries) to illustrate your approach.

Input and output designs: Provide sample rough designs of inputs and outputs, including forms and reports. Show examples of the human-computer interface design.

Library software: Explain any library software you plan to use, such as scientific or data visualisation libraries.

Database or web frameworks: Document any database systems or web design frameworks you intend to use.

Screenshots from the programmed solution: It's acceptable to include screenshots of aspects of the design from your completed programmed solution, even though you won't actually produce these until the technical solution stage is complete.

Technical solution section (42 marks)

This is where the bulk of marks are awarded. The technical solution is the heart of your NEA - the actual programmed system you create. This section is split into two distinct components.

Part 1: Completeness of the solution (15 marks)

The first component assesses how well your solution meets the requirements you identified in your analysis. Your work will fall into one of three bands:

• Meets almost all requirements
• Meets many requirements
• Meets some requirements

The total marks awarded depend on the assessor's judgement. If you can't meet all requirements, make sure you identify and successfully implement the main requirements of the system. Focus on the core functionality rather than trying to do everything.

Part 2: Techniques used (27 marks)

The second component evaluates how proficient you are at using specific programming techniques. To be considered proficient means you've successfully implemented a particular feature of the code - your code must actually work.

The assessment uses two AQA reference tables:

Table 1 (3.14.3.4.1) - Example technical skills: This provides three lists of programming algorithms and techniques, labelled A, B, and C. List A contains the most complex techniques, while list C contains the simplest.

Table 2 (3.14.3.4.2) - Coding styles: This shows the level of proficiency you might achieve when using the techniques from the first table. You can be awarded ratings of Excellent, Good, or Basic.

Evidence you must provide

To prove you've fully implemented your design, include comprehensive documentation:

Self-documenting code: Write code that uses meaningful identifiers, logical structures, and annotation (comments) so that a third party can understand it.

Overview guide: Create a guide that includes the names of entities such as executables, data filenames and URLs, database names, and pathnames.

Explanations: Provide explanations of particularly difficult-to-understand code sections.

Code organisation: Carefully divide your code listing into appropriately labelled sections for easy navigation.

Testing section (8 marks)

Testing demonstrates that your system works correctly and robustly. You must provide evidence that systematic testing has been carried out and that the tests were designed to ensure the system functions as specified. You don't need to document every single test, but you do need a representative sample showing each type of test.

What to include in your testing

Your testing documentation should cover:

Test strategy overview: Explain your overall approach to testing, including what test data you'll use.

Test data types: Use three categories of test data:

• Normal (typical) data: Standard inputs that the system should handle correctly
• Boundary data: Values at the edges of acceptable ranges
• Erroneous data: Invalid inputs that the system should reject appropriately

Individual function tests: Test individual functions and components.

Whole system tests: Conduct tests that demonstrate the original objectives have been met. These should show how the complete system works together.

Evidence of testing: Include annotated hard copies of your tests, tables showing expected versus actual outcomes, and samples of screenshots or actual print-outs as evidence.

The tests should ensure coverage of the main objectives of your project.

Assessment criteria for testing

Your testing will be marked according to two main criteria:

• Clear, well-presented evidence of testing
• Evidence that the testing proves the system is robust and works as intended

Evaluation section (4 marks)

The evaluation is your opportunity to honestly reflect on whether your project has been successful. It's important to be truthful rather than claiming everything worked perfectly if it didn't.

What to include in your evaluation

Structure your evaluation around these key elements:

Objectives review: Copy the original objectives you wrote in the analysis section. Go through each one and explain whether you met it. If you successfully met an objective, explain how effectively it was achieved. If you didn't meet an objective, explain why not.

User feedback: Give your user a chance to use the system and ask them for both general and specific comments. Don't invent user or supervisor feedback - it will be obvious if you do.

Responding to feedback: Address the feedback you received, explaining how you might incorporate any changes the user requested.

System improvements: Based on the feedback and your own opinions, identify ways the system could be improved or enhanced.

Assessment criteria for evaluation

Your evaluation will be marked according to three main criteria:

• Whether you've considered and addressed suggestions for improvements
• Whether you've obtained real feedback from your user(s) or supervisor
• Whether you've fully considered how well the solution meets its objectives

General advice for success

The A-level NEA is a major undertaking, and getting a good mark requires significant effort. Students who excel in coursework tend to achieve the best overall A-level grades. There's a comforting aspect to this: when you enter the exam, you'll already have a good mark secured from your project. Conversely, a poor project mark means you'll have considerable ground to make up in the exam.

Remember!