📚 Year 13 AQA Computer Science: Key Points for Practical Project (NEA) Assessment | Year 13 AQA 计算机科学实践项目（NEA）考核要点
The Non-Exam Assessment (NEA) in Year 13 is a substantial programming project that contributes 20% towards your final AQA A-level Computer Science grade. It demands not only technical coding ability but also a structured approach to analysis, design, testing, and evaluation. This article distils the essential practical assessment points you must master to achieve top marks.
Year 13 的非考试评估 (NEA) 是一个重要的编程项目，占你 AQA A-level 计算机科学最终成绩的 20%。它不仅要求技术编程能力，还要求对分析、设计、测试和评估采取结构化的方法。本文提炼了必须掌握的关键实践考核要点，以帮助获得高分。
1. Understanding the NEA Structure and Stakes | 理解 NEA 的结构与分量
The AQA A-level Computer Science NEA (7517/C) is an independent project worth 75 marks, equivalent to 20% of the A-level. You must choose a real-world problem, then produce a complete software solution with comprehensive documentation. The project is internally assessed by your teacher and externally moderated by AQA.
AQA A-level 计算机科学 NEA（卷 7517/C）是一个独立的项目，共 75 分，占 A-level 成绩的 20%。你必须选择一个真实世界的问题，然后产出一个完整的软件解决方案并附上全面文档。项目由教师内部评估，并由 AQA 外部抽样审核。
The final submission typically includes a written report and an executable program. The report is broken down into five marked sections: Analysis (9 marks), Design (12 marks), Technical Solution (42 marks), Testing (12 marks), and Evaluation (15 marks). Eighty percent of the marks come from your actual solution and its evaluation, so hands‑on coding and reflective commentary are paramount.
最终提交物通常包括一份书面报告和一个可执行程序。报告分为五个计分部分：分析（9 分）、设计（12 分）、技术解决方案（42 分）、测试（12 分）和评估（15 分）。80% 的分数来自实际方案及其评估，因此动手编程与反思性评论至关重要。
2. Project Analysis and Requirements (Section A) | 项目分析与需求（A 部分）
The Analysis section must clearly define the problem and the stakeholder needs. Start by outlining the background and the context of the chosen problem, then produce a numbered list of specific, measurable objectives. Use interviews, questionnaires, or existing system reviews to gather evidence of genuine user requirements.
分析部分必须清晰定义问题与利益相关者需求。先概述所选问题的背景与情境，然后列出一组编号的、具体可衡量的目标。利用访谈、问卷或现有系统评审来收集真实用户需求的证据。
A data model and a high-level process model (such as a flow chart) are expected. You also need to identify the hardware and software requirements, licensing, and any constraints. AQA rewards an analysis that shows data flows between entities and considers ethical or legal issues, such as GDPR compliance if personal data is involved.
你需要提供数据模型和高层流程模型（如流程图），并明确硬件和软件需求、许可证及任何限制。AQA 奖励那些展示了实体间数据流动、并考虑了道德或法律问题（如涉及个人数据时的 GDPR 合规）的分析。
The objectives must act as a contract: they will be revisited during testing and evaluation. Avoid vague statements like "make a game". Instead, write precise objectives such as "The system shall allow a user to register with a unique username and password, and validate the email address using regex".
这些目标必须起到“合同”作用：它们将在测试与评估阶段被重新审视。避免模糊表述，如“制作一个游戏”。相反，应写下精确的目标，例如“系统应允许用户使用唯一用户名和密码注册，并使用正则表达式验证电子邮件地址”。
3. Designing the Solution (Section B) | 设计解决方案（B 部分）
Design is your blueprint. You need to provide a modular structure diagram showing how the system is decomposed into components or classes. AQA expects detailed algorithmic designs for key processes, often expressed in pseudo‑code or structured English, and fully annotated class diagrams if using an object‑oriented approach.
设计是你的蓝图。你需要提供模块结构图，展示系统如何分解为组件或类。AQA 期望对关键流程进行详细的算法设计，通常以伪代码或结构化英语表达，如果采用面向对象方法，还需提供完整注释的类图。
Database designs must include an entity‑relationship diagram (ERD) and a data dictionary specifying tables, fields, data types, lengths, keys, and validation rules. User interface (UI) designs—wireframes or screen mock‑ups—should be annotated to explain navigation and event handling.
数据库设计必须包括实体关系图 (ERD) 和数据字典，后者要详细列出表、字段、数据类型、长度、键和验证规则。用户界面 (UI) 设计——线框图或屏幕模型——应添加注释以说明导航和事件处理。
Your design must justify choices. For every algorithm or structure, briefly explain the rationale (e.g., why a binary search tree over a hash table for a particular function). All designs should trace back to the objectives in Analysis, demonstrating clear traceability.
你的设计必须对选择做出解释。针对每个算法或结构，简要说明理由（例如，为何在特定功能中选择二叉搜索树而非哈希表）。所有设计都应追溯回分析部分的目标，展示清晰的可追溯性。
4. Technical Solution and Coding (Section C) | 技术解决方案与编码（C 部分）
This is the core of the assessment, worth a massive 42 marks. You need to deliver a fully functional, well-structured program. AQA explicitly looks for complex programming techniques, including use of arrays/lists, file handling, object‑oriented programming (OOP) concepts like inheritance and polymorphism, recursion, and appropriate data structures.
这是评估的核心，分值高达 42 分。你需要交付一个功能完整、结构良好的程序。AQA 明确要求展示复杂编程技术，包括使用数组/列表、文件处理、面向对象编程概念（如继承和多态）、递归以及合适的数据结构。
Your code must be robust, with input validation and exception handling throughout. Comment your code effectively—explain the ‘why’ not the ‘what’. In the report, you must present selected code listings with clear explanations, showing how they contribute to the solution objectives. Do not print out the entire source; choose key algorithms and critical modules.
你的代码必须健壮，处处包含输入验证和异常处理。注释要有效——解释“为什么”而不是“是什么”。在报告中，你必须呈现精选的代码清单并附上清晰说明，展示它们如何有助于实现解决方案目标。切勿打印全部源代码；只挑选关键算法和主要模块。
Evidence of 'code growth' or iterative development is highly valued. Keep regular dated snapshots or use a version control system (e.g., Git) to demonstrate how the program evolved. Show that you can refactor and improve your code based on testing outcomes.
“代码成长”或迭代开发的证据非常受重视。保留定期带有日期的快照，或使用版本控制系统（如 Git），以展示程序如何演进。展示你能根据测试结果重构和改进代码。
5. Testing Strategies (Section D) | 测试策略（D 部分）
Testing is worth 12 marks and must be both systematic and thorough. Start with a clear test plan that covers all functional and non‑functional requirements from your Analysis. Test tables should include test ID, description, test data (normal, boundary, erroneous), expected result, actual result, and a pass/fail column.
测试部分占 12 分，必须系统且全面。首先制定一个清晰的测试计划，覆盖分析部分的所有功能和非功能需求。测试表格应包含测试编号、描述、测试数据（正常、边界、错误）、预期结果、实际结果和通过/失败列。
You must demonstrate corrective action: if a test fails, show the debugged code and a re‑test. AQA expects evidence of user testing—collect feedback through questionnaires and document the outcomes. This shows interaction with real stakeholders and validates the solution in a practical context.
你必须展示纠正措施：如果测试失败，要呈现调试后的代码以及重新测试。AQA 期望有用户测试的证据——通过问卷收集反馈并记录结果。这展示了你与真实利益相关者的互动，并在实际环境中验证了解决方案。
In addition to functional testing, include performance testing (if relevant) or load testing for web‑based systems. Trace each test back to a specific objective, confirming that every goal set out in Analysis has been met.
除功能测试外，如果需要，还应包括性能测试或基于 Web 系统的负载测试。让每一项测试都追溯回一个具体目标，确认分析中设定的每个目标都已达成。
6. Evaluation and Reflection (Section E) | 评估与反思（E 部分）
The Evaluation section carries 15 marks and requires a critical reflection on the project. Start by comparing the final product against each original objective. For any objective not fully met, explain why and what could be done differently. Never try to hide limitations—acknowledging them with insight gains marks.
评估部分占 15 分，要求对项目进行批判性反思。首先将最终产品与每一个初始目标进行比较。对于任何未能完全达成的目标，要解释原因并提出改进做法。切莫试图掩盖局限——有见地地承认局限反而能得分。
Discuss the usability of the software based on user feedback. What did stakeholders like, and what frustrated them? Include direct quotes from feedback forms. Also, reflect on your own development process—what programming skills did you develop, and how would you manage a similar project in the future?
依据用户反馈讨论软件的可用性。利益相关者喜欢什么，什么让他们感到挫败？引用反馈表中的原话。同时，反思你自己的开发过程——你发展了哪些编程技能，未来你会如何管理类似项目？
A strong evaluation proposes genuine, implementable extensions. Instead of generic statements like “add more features”, propose a specific feature such as integrating a machine learning API for personalised recommendations, and briefly outline how you would implement it.
一份强评估会提出真实、可实施的扩展。与其泛泛地说“增加更多功能”，不如提出一个具体功能，比如集成机器学习 API 实现个性化推荐，并简要勾勒实现方案。
7. Marking Criteria and Weighting Breakdown | 评分标准与权重分解
the mark allocation helps you prioritise effort. Technical Solution dominates (42/75 = 56%), while Design and Testing together account for another 32% hough smaller, are often where candidates drop marks due to vagueness or lack of evidence.
了解分值分配有助于你优先安排精力。技术解决方案占主导（42/75 = 56%），而设计与测试合起来占 32%。分析与评估虽分值较少，但往往是考生因表述模糊或缺乏证据而失分的地方。
| Section | Marks | Key focus |
|---|---|---|
| Analysis | 9 | Clear objectives, stakeholder evidence |
| Design | 12 | Algorithms, data structures, UI, justification |
| Technical Solution | 42 | Functioning code, complexity, robustness |
| Testing | 12 | Plan, data, corrective actions, user testing |
| Evaluation | 15 | Objective review, reflection, extensions |
Aim to integrate evidence throughout the report. For instance, link a screenshot of a working feature to its design, and then to the test that validates it. This seamless thread across sections raises the overall quality perception.
力求在报告中处处整合证据。例如，将一个工作功能的截图链接到其设计，再链接到验证它的测试。这种跨部分的连贯线索能提升整体质量印象。
8. Evidence and Documentation Essentials | 证据与文档要点
Your NEA report is not just text; it must be rich in annotated screenshots, code snippets, diagrams, and tables. Every claim you make—like “the program handles errors”—must be backed by visible evidence. AQA moderators want to see a “live” project through your documentation.
你的 NEA 报告不仅仅是文字；它必须包含丰富的注释截图、代码片段、图表和表格。你所做的每一个声明——如“程序处理了错误”——都必须有可见证据支撑。AQA 审核员希望通过你的文档看到一个“活的”项目。
Organise your report logically with a contents page and clear headers. Include a video or screen recording of the program running, as this can dramatically convey the scope of your work. Ensure all evidence is clearly labelled and referenced in the text (e.g., “see Figure 12”).
合理组织报告，配上目录页和清晰的页眉。包含一段程序运行的视频或屏幕录制，这能极大地传达你的工作范围。确保所有证据都有清晰标注并在正文引用（如“见图 12”）。
For code listings, use a monospaced font and highlight key lines. Avoid submitting the entire project source as an appendix; instead, embed only the most significant sections with commentary. Your teacher will have access to the full codebase separately.
对于代码清单，使用等宽字体并突出关键行。不要将整个项目源代码作为附录提交；只需嵌入最重要的部分并附上评论。你的老师将另行访问完整的代码库。
9. Time Management and Milestones | 时间管理与里程碑
The NEA spans several months in Year 13, typically from June of Year 12 to March of Year 13. Break the project into stages: problem identification (summer), analysis and design completed by October, prototype by December, full implementation and testing by February, and evaluation/report finalisation by March.
NEA 贯穿 Year 13 数月，通常从 Year 12 的六月持续到 Year 13 的三月。将项目分解为阶段：问题识别（暑假）、分析设计在十月前完成、十二月前完成原型、二月前完成完整实现与测试、三月前完成评估与报告定稿。
Set weekly targets and maintain a development log. This log not only helps with timeliness but also serves as evidence of iterative development. Regularly consult your teacher for formative feedback—AQA allows generic guidance, and acting on it shows responsiveness.
设定每周目标并维护一份开发日志。这份日志不仅有助于按时推进，还可作为迭代开发的证据。定期向老师寻求形成性反馈——AQA 允许一般性指导，而据此采取行动能体现你的应变能力。
Avoid the trap of leaving all documentation to the end. Writing the report alongside the code saves time and preserves fresh insights. Design your report template early and fill sections incrementally after each achieved milestone.
要避免将所有文档留到最后才写的陷阱。边编码边撰写报告能节省时间并保留新鲜见解。提早设计好报告模版，在达成每个里程碑后逐步填充各部分。
10. Coding Best Practices for Assessment | 考核中的编码最佳实践
Use meaningful variable names, consistent indentation, and a clear code structure. Even though the full source may not be submitted in the report, the quality of the listings you present will be scrutinised. AQA values self‑documenting code complemented by well‑judged comments.
使用有意义的变量名、一致的缩进和清晰的代码结构。即便完整源码可能不随报告提交，你所呈现的代码片段质量仍会被审视。AQA 看重自文档化的代码并辅以恰当的注释。
Employ the principles of modular programming: break complex tasks into small, reusable functions or methods with single responsibilities. This not only enhances readability but also makes unit testing straightforward, which you can then evidence in Section D.
运用模块化编程原则：将复杂任务分解为单一职责的小型可复用函数或方法。这不仅增强了可读性，也使单元测试变得直接，继而可在 D 部分作为证据。
Where possible, adopt design patterns or standard algorithms (e.g., merge sort, Dijkstra's algorithm) and cite them. Avoid copying large blocks of code from online sources; if you do use external libraries or snippets, make sure you understand and can explain them, and credit the source appropriately.
尽可能采用设计模式或标准算法（如归并排序、Dijkstra 算法）并加以引用。避免从网络来源拷贝大段代码；如果使用外部库或代码片段，务必确保自己理解并能够解释，同时恰当地注明来源。
11. Common Pitfalls to Avoid | 常见陷阱及避免方法
Pitfall 1: Over‑ambitious scope. Choosing a project that is too large leads to incomplete functionality and shallow documentation. Instead, pick a manageable problem that still permits demonstration of advanced techniques.
陷阱一：目标过于宏大。选择过大的项目会导致功能不完整和文档肤浅。应选择范围可控但仍能展示高级技巧的问题。
Pitfall 2: Weak traceability. If objectives, design elements, code, and tests are not explicitly linked, the report appears disjointed. Use a requirement traceability matrix or numbering system to connect everything.
陷阱二：可追溯性薄弱。如果目标、设计元素、代码和测试未明确关联，报告会显得支离破碎。使用需求追溯矩阵或编号系统将所有内容联系起来。
Pitfall 3: Ignoring the evaluation. Candidates often run out of time and write a superficial evaluation. Plan to spend at least two weeks on evaluation, collecting final user feedback and crafting a thoughtful reflection.
陷阱三：忽视评估。考生常因时间不够而写出肤浅的评估。规划至少花两周时间进行评估，收集最终用户反馈并撰写深思熟虑的反思。
Pitfall 4: Inadequate error handling. Programs that crash due to unhandled exceptions signal fragile code. Always validate user input and use try‑catch blocks where exceptions may arise; then document this robustness in your report.
陷阱四：错误处理不足。因未处理异常而崩溃的程序表明代码脆弱。务必验证用户输入，在可能发生异常的位置使用 try‑catch 块；然后在报告中记录这种鲁棒性。
12. Final Submission Checklist | 最终提交清单
Before submitting, verify the following: report includes all five sections with clear headings; every objective is tested and cross‑referenced; all screenshots and code snippets are legible and annotated; user testing feedback is attached; and a working executable is provided on a suitable medium. Double‑check that the report page count guidelines (often 100-150 pages) are met without padding.
提交前，请核对以下事项：报告包含所有五部分且标题清晰；每个目标都经过测试并交叉引用；所有截图和代码片段清晰可读且附有注释；用户测试反馈已附上；并在合适介质上提供了可正常工作的可执行文件。再次检查是否满足了报告页数指引（通常 100-150 页）而无注水内容。
Run the program from submission media on a clean machine to ensure all dependencies are included. The code must compile and run without errors. Finally, ensure the report PDF is well‑structured with working internal links and bookmarks for easy navigation.
在一台干净机器上从提交介质运行程序，确保所有依赖项都已包含。代码必须能无错编译运行。最后，确保报告 PDF 结构良好，带有可用的内部链接和书签，便于导航。
In the closing stages, ask a peer to proofread the documentation for consistency between diagrams, code, and written description. A fresh pair of eyes often spots missing gaps that you have overlooked.
在收尾阶段，请同伴通读文档，检查图表、代码和文字描述的一致性。一双新鲜的眼睛常能发现你忽视的遗漏之处。
Published by TutorHao | Computer Science Revision Series | aleveler.com
更多咨询请联系16621398022（同微信）
或截图后用「扫一扫 → 相册」选择本图