📚 Year 13 WJEC Computer Science: NEA Practical Assessment Key Points | WJEC 计算机 A2 实践考核要点
The WJEC A Level Computer Science NEA (Non-Exam Assessment) is a crucial component that tests your ability to analyse, design, implement and evaluate a real-world programming solution. This guide covers the essential key points to help you achieve top marks in your Year 13 practical project.
WJEC A Level 计算机科学的非考试评估（NEA）是测试你分析、设计、实现和评估真实世界编程解决方案能力的关键组成部分。本指南涵盖核心要点，助你在 Year 13 实践项目中取得高分。
1. Understanding the NEA Requirements | 理解 NEA 要求
The WJEC Component 3 NEA is worth 20% of the A Level and marked out of 80 raw marks. It assesses your ability to produce a documented programmed solution to a real problem, covering analysis, design, development, testing and evaluation. You must demonstrate technical proficiency as well as systematic project management.
WJEC 的 Component 3 NEA 占 A Level 总分的 20%，原始分数为 80 分。它评估你针对实际问题给出有文档记录的编程解决方案的能力，涵盖分析、设计、开发、测试和评估。你必须同时展现技术熟练度与系统的项目管理。
The assessment is split into five key sections: Analysis (6 marks), Design (12 marks), Software Development (30 marks), Testing and Evaluation (16 marks), and Documentation (16 marks). Each section has banded descriptors, so it is vital to know what the examiners are looking for before you start.
评估分为五个关键部分：分析（6 分）、设计（12 分）、软件开发（30 分）、测试与评估（16 分）以及文档（16 分）。每个部分都有分档描述，因此在开始前了解考官期望至关重要。
2. Choosing a Suitable Problem | 选择合适的题目
Select a problem that is complex enough to allow you to demonstrate a range of programming skills, yet realistic to complete within the time frame. A database-driven system, a simulation, a mobile app with data processing, or a game with AI opponents can work well, provided you can explain the algorithmic challenges.
选择一个足够复杂、能让你展示多种编程技能的问题，同时也要在时间范围内实际可行。带有数据库的系统、模拟程序、带数据处理的移动应用或含 AI 对手的游戏都可以，前提是你能解释其中的算法挑战。
Ensure the problem has a clearly defined end-user who can give you feedback during testing. A vaguely defined problem will lead to weak analysis and evaluation. Avoid overly simple CRUD (Create, Read, Update, Delete) applications unless they include significant algorithmic complexity, such as pathfinding or data analysis.
确保待解决的问题有明确的终端用户，以便在测试阶段能给予反馈。定义模糊的问题会导致分析和评估薄弱。除非涉及路径查找或数据分析等显著的算法复杂性，否则避免过于简单的 CRUD 应用。
3. Analysis: Capturing Stakeholder Requirements | 分析：获取利益相关者需求
Start by identifying all stakeholders, including users, maintainers and possibly an organisation. Describe their needs in specific, measurable terms. Use interviews, questionnaires or observation records as evidence, and present this information in a structured table. A strong analysis sets the foundation for the entire project.
首先识别所有利益相关者，包括用户、维护人员甚至组织。用具体、可衡量的术语描述他们的需求。使用访谈、问卷或观察记录作为证据，并以结构化表格呈现这些信息。扎实的分析是整个项目的基础。
Write clear, measurable objectives. For example: 'The system shall allow a librarian to search for a book by ISBN and display availability within 2 seconds.' Avoid vague statements like 'The system should be fast.' Each objective must be traceable to later design and testing stages.
写出清晰、可量化的目标。例如：“系统应允许图书馆员按 ISBN 搜索图书并在 2 秒内显示可借状态。”避免“系统应该很快”这类含糊表述。每个目标必须能追溯到后续的设计和测试阶段。
4. Analysis: Modelling with DFDs and Flowcharts | 分析：用数据流图和流程图建模
To score highly, you must model the current system and the proposed solution. Level 0 and Level 1 Data Flow Diagrams (DFDs) are expected to show how data moves. Use recognised Gane & Sarson or Yourdon notation. Annotate them to explain the processes, data stores and external entities.
要拿高分，必须对现有系统和提议方案进行建模。应提供 0 级和 1 级数据流图（DFD）来展示数据如何流动。使用公认的 Gane & Sarson 或 Yourdon 符号，并添加注释来解释过程、数据存储和外部实体。
Additionally, produce structure charts or high-level flowcharts that outline the main modules of your program. Include a data dictionary listing all variables, data types and validation rules. This analysis documentation proves you have fully grasped the problem before moving to design.
此外，还需制作结构图或高层流程图来概述程序的主要模块。同时包含列出所有变量、数据类型和验证规则的数据字典。这些分析文档可以证明你在进入设计阶段前已完全理解了问题。
5. Design: System Architecture and Data Structures | 设计：系统架构与数据结构
Your design section must cover the overall system architecture, including hardware and software requirements, and how the components interact. If you use a database, supply an entity-relationship diagram (ERD) with normalised tables up to third normal form (3NF). Justify your choice of data structures, e.g. 'I opted for a hash table to achieve O(1) average lookup for user IDs.'
设计部分必须涵盖包括软硬件要求以及组件间如何交互在内的整体系统架构。如果使用数据库，需提供实体关系图（ERD）和规范化为第三范式（3NF）的表。同时要说明选择数据结构的理由，例如：“我选择哈希表是为了在用户 ID 查找上实现 O(1) 的平均时间复杂度。”
For object-oriented projects, produce a UML class diagram showing inheritance, composition and key methods. For procedural projects, provide a module dependency diagram. All design choices should link back to the objectives identified in your analysis; this traceability is rewarded under the band descriptors.
对于面向对象项目，需制作 UML 类图来展示继承、组合关系和关键方法。对于过程式项目则应提供模块依赖图。所有设计选择都应追溯到分析阶段确定的目标；这种可追溯性在评分档次描述中是加分的。
6. Design: Detailed Algorithms and UI Prototypes | 设计：详细算法与界面原型
Provide pseudocode or detailed stepwise refinement for all non-trivial algorithms. Use a consistent style, such as 'INPUT, PROCESS, OUTPUT' structure, and include comments on complexity. For any algorithm with O(n²) or higher, discuss the rationale and potential alternatives.
为所有非平凡的算法提供伪代码或详细的逐步求精描述。采用一致风格，比如“输入、处理、输出”结构，并添加关于复杂度的注释。对于任何复杂度达 O(n²) 或更高的算法，讨论其合理性及可能的替代方案。
Create wireframes or mock-ups of key user interfaces, showing how the user navigates between screens. Link each UI element to a functional requirement. This demonstrates thoughtful design and makes later evaluation much easier, as you can compare the final product against these initial plans.
制作关键用户界面的线框图或模型，展示用户如何在屏幕之间导航。将每个 UI 元素与功能需求对应起来。这体现了周全的设计，也使后续评估更为容易，因为你可以将最终产品与这些初始计划进行对比。
7. Software Development: Coding Best Practices | 软件开发：编程最佳实践
This section carries the most marks (30 out of 80). You must provide evidence of a working solution through annotated code listings, screenshots and clear explanations of key algorithms. Use meaningful variable names, consistent indentation and internal commentary (not just restating the code).
这一部分分值最高（80 分中的 30 分）。你必须通过注释过的代码清单、屏幕截图和清晰的关键算法解释来提供可运行解决方案的证据。使用有意义的变量名、一致的缩进以及有见地的内部注释（而不仅仅是复述代码）。
Show evidence of advanced programming techniques, such as recursion, file handling, exception management, data structures (e.g. stacks, queues, trees), and object-oriented features like polymorphism if appropriate. Include defensive programming measures that handle invalid inputs gracefully without crashing.
展示高级编程技术的证据，如递归、文件处理、异常管理、数据结构（如栈、队列、树）以及在适当时使用多态等面向对象特性。同时包含防御性编程手段，能优雅地处理无效输入而不会崩溃。
Ensure you maintain a version control log or a diary of build iterations. This demonstrates a systematic development approach. The examiner wants to see that you have refined the product over time rather than presenting a single final version with no evolution.
确保维护一份版本控制日志或构建迭代日记。这体现了系统的开发方法。考官希望看到的是你不断打磨产品，而非只呈现一个没有演进过程的最终版本。
8. Testing: Building a Comprehensive Test Plan | 测试：制定全面的测试计划
Create a test plan table that includes test ID, test criteria, test data (normal, boundary, erroneous), expected results, actual results and a pass/fail column. You should also indicate which objective or requirement each test corresponds to. A minimum of 20–30 well-chosen tests is typical for a top-band project.
制作一个测试计划表，包含测试 ID、测试标准、测试数据（正常值、边界值、错误值）、预期结果、实际结果以及通过/失败列。同时应标明每个测试对应哪个目标或需求。一个高分项目通常至少需要 20-30 个精心设计的测试。
| Test ID | Data | Expected | Actual | Pass/Fail |
|---|---|---|---|---|
| T01 | ISBN 9780141180663 | Book details displayed | Book details displayed | Pass |
| T02 | Empty string | Error message 'Enter ISBN' | Error message shown | Pass |
After functional testing, perform user acceptance testing. Document feedback from real users and log any issues you fix. Include screenshots of before-and-after corrections. This proves that you have responded to real-world feedback, which is essential for high evaluation marks.
功能测试完成后，进行用户验收测试。记录真实用户的反馈，并记录你修复的所有问题。附上修正前后的对比截图。这证明你响应了真实世界的反馈，这对于获得高评估分至关重要。
9. Evaluation: Reflecting on Success and Limitations | 评估：反思成功与不足
A strong evaluation goes beyond simply stating 'the project met its objectives'. For each objective, discuss how well it was met, supported by evidence from testing. If an objective was partially met, explain why and suggest realistic improvements that could be made with more time or resources.
出色的评估不应该只是简单说“项目达成了目标”。对于每个目标，要结合测试证据讨论其实现程度。如果某个目标部分达成，需解释原因，并提出在更多时间或资源下可做出的现实改进。
You should also evaluate the effectiveness of your chosen algorithms, data structures and development methodology. Refer back to the design section and highlight trade-offs. For example, 'While Dijkstra's algorithm gave accurate shortest paths, its O((V+E) log V) running time could be reduced by A* search with a heuristic in a map-based application.'
你还应评估所选算法、数据结构和开发方法的有效性。回溯设计部分，突出其中的权衡取舍。例如：“虽然 Dijkstra 算法给出了精确的最短路径，但其 O((V+E) log V) 的运行时间在这样的地图应用中有可能通过带启发式函数的 A* 搜索来进一步降低。”
10. Documentation: Creating a Professional Report | 文档：制作专业报告
The documentation mark (16 marks) is awarded for the quality of the overall project report, not just the code comments. Your report should be well-structured with a cover page, contents table, clear section numbering, consistent fonts, and thorough proofreading. Treat it as a professional technical document.
文档分数（16 分）是针对整个项目报告的质量，而不仅仅是代码注释。你的报告应结构良好，包含封面页、目录、清晰的章节编号、统一的字体，并经仔细校对。把这当作一份专业的技术文档来对待。
Include a user guide with installation instructions, screenshots of every major feature and a troubleshooting section. A technical guide is also valuable, describing how to compile or run the code, the software dependencies, and how to configure the database if applicable.
包含一本用户指南，内含安装说明、每个主要功能的屏幕截图以及故障排除部分。同样有价值的是技术指南，描述如何编译或运行代码、软件依赖性以及（如适用）如何配置数据库。
Use automated tools for generating references if you cite any sources. Ensure that all diagrams are legible and captioned. The examiner will look at the overall presentation; a messy report can cost you easy marks even if the software is brilliant.
如果引用任何来源，使用自动工具生成参考文献。确保所有图表清晰可读并配有图注。考官会关注整体呈现效果；即使软件十分出色，一份杂乱无章的报告也可能让你丢掉本应容易拿到的分数。
11. Time Management and Project Planning | 时间管理与项目规划
From the start, create a Gantt chart breaking down the project into phases with milestones. Allocate ample time for testing and documentation, which are often rushed. Plan for at least two full iterations of design, code and test to allow refinement based on feedback.
从一开始就制作一张甘特图，将项目分解为带有里程碑的阶段。为测试和文档留出充足时间，这些往往是最后仓促完成的。至少规划两轮完整的设计、编码和测试迭代，以便根据反馈进行打磨。
Keep a weekly project log where you note progress, problems and solutions. This log not only helps you stay on track but also serves as evidence of a systematic approach, which the marking criteria reward. Do not underestimate the value of showing your working process.
坚持每周写项目日志，记录进度、问题和解决方案。这份日志不仅帮助你按计划推进，还能作为系统性方法的有力证据，这是评分标准所嘉奖的。不要低估展示工作过程的价值。
12. Common Pitfalls to Avoid | 需要避免的常见错误
Avoid a project that is either too trivial or too ambitious. A complex plan that results in an unfinished product will lose development marks. Similarly, avoid a purely visual project with no algorithmic depth; the NEA is about computing, not just graphic design.
避免选择过于琐碎或过于雄心勃勃的项目。一个复杂却未完成的计划会丢失开发分数。同样，也要避免纯粹视觉化而缺乏算法深度的项目；NEA 关乎计算，而不仅是图形设计。
Never claim a test has passed if you cannot show an actual result screenshot. Undocumented tests are worthless. Also, refrain from submitting a report full of uncommented code or incomprehensible diagrams. Finally, ensure you adhere to the official WJEC submission guidelines regarding file format, naming conventions and authenticity declaration.
如果无法提供实际结果的截图，千万不要声称某测试已通过。没有记录文档的测试毫无价值。另外，不要提交一份满是未注释代码或无法理解的图表的报告。最后，务必遵守 WJEC 官方提交流程，包括文件格式、命名约定和真实性声明。
Published by TutorHao | Computer Science Revision Series | aleveler.com
更多咨询请联系16621398022（同微信）
或截图后用「扫一扫 → 相册」选择本图