📚 Year 13 Edexcel Computer Science: Practical Assessment Essentials | Year 13 Edexcel 计算机：实践考核要点
The Year 13 Edexcel A Level Computer Science practical assessment, known as the Non-Exam Assessment (NEA) programming project, is the keystone of your final grade. This self-directed piece of work requires you to analyse, design, develop, test and evaluate a substantial software solution for a genuine stakeholder, showcasing your computational thinking and coding craftsmanship. Mastering the NEA demands more than clever code — it's about systematic documentation, rigorous testing and clear justification of every decision.
Year 13 Edexcel A Level 计算机科学的实践考核，即非考试评估（NEA）编程项目，是最终成绩的基石。这项自主性作业要求你为真实用户分析、设计、开发、测试并评估一个规模可观的软件解决方案，全面展现你的计算思维和编码功底。掌握 NEA 不止需要巧妙的代码——更在于系统化文档、严格测试和对每个决策的清晰论证。
1. Understanding the NEA Structure | 理解 NEA 的整体结构
The Edexcel NEA is marked out of 75 and accounts for 20% of the A Level. It is divided into four main sections: Analysis (12 marks), Design (15 marks), Development and Testing (26 marks), and Evaluation (22 marks). You must produce a single PDF document that integrates all evidence, together with a working program. The project is internally assessed and externally moderated, so your write-up must stand alone as proof of your technical journey.
Edexcel NEA 满分 75 分，占 A Level 总成绩的 20%。它分为四大板块：分析（12 分）、设计（15 分）、开发与测试（26 分）、评估（22 分）。你需要提交一份整合所有证据的 PDF 文档，以及可运行的程序。该项目由校内评分、外部审核，因此你的报告必须独立地证明整个技术历程。
- The report must clearly identify the client, their needs and the real-world context.
- 报告必须清楚标明客户、需求及现实应用背景。
- All evidence, from early sketches to final test logs, should be threaded into a coherent narrative.
- 所有证据，从早期草图到最终测试日志，都应串联成一个连贯的叙事。
- Marks are awarded for depth and justification, not just a long document.
- 得分取决于深度和论证，而非文档长度。
2. Selecting a Suitable Stakeholder and Problem | 选择合适的利益相关者与问题
A genuine end-user is non-negotiable. Pick someone with a real computational need — a small business owner struggling with inventory, a teacher overwhelmed by report generation, or a charity tracking volunteer hours. The problem must be complex enough to require algorithmic thinking, data structures and a user interface. Avoid trivial problems like a simple calculator; the project scope should allow for features such as file handling, searching, sorting and user authentication.
真实的终端用户是硬性要求。选择有真实计算需求的人——比如为库存发愁的小企业主、被报告生成搞得焦头烂额的教师，或是追踪志愿者工时的慈善机构。问题必须足够复杂，需要算法思维、数据结构和用户界面。避免如简单计算器之类的琐碎问题；项目范围应允许实现文件处理、搜索、排序和用户认证等功能。
- Draft a clear statement of the problem with measurable objectives.
- 拟定清晰的问题陈述，包含可量化的目标。
- Verify the stakeholder is accessible for feedback throughout the development cycle.
- 确认在整个开发周期中利益相关者都能提供反馈。
- Consider ethical and legal data implications early (GDPR).
- 尽早考虑数据处理的伦理和法律影响（通用数据保护条例）。
3. Rigorous Analysis of Requirements | 严格的需求分析
Analysis is the foundation of your project. Decompose the problem using computational thinking: identify inputs, processes, outputs and data storage. You must produce a detailed list of functional and non-functional requirements, justified by interviews, questionnaires or observation of the current system. Use tools like data flow diagrams (DFD Level 0 and Level 1), system flowcharts or entity-relationship diagrams to model the problem domain. Every requirement should be traceable to a stakeholder need.
分析是项目的基础。运用计算思维分解问题：识别输入、处理、输出与数据存储。你必须产出一份详尽的功能与非功能需求清单，并通过面谈、问卷或对现行系统的观察加以论证。使用数据流图（0 级与 1 级 DFD）、系统流程图或实体关系图等工具对问题域建模。每条需求都应能追溯至某项利益相关者需求。
- Functional requirements: exactly what the system must do (e.g., 'search product by barcode').
- 功能需求：系统必须做的事（如“按条形码搜索产品”）。
- Non-functional: constraints like response time, security, platform.
- 非功能需求：如响应时间、安全性、运行平台等约束条件。
- Include a justification for the proposed computational approach (e.g., why OOP over procedural).
- 解释所选计算方法的理由（比如为何选择面向对象而非过程式）。
4. Design: Creating a Coherent Blueprint | 设计：打造连贯的蓝图
Your design section must cover overall system architecture, algorithms, data structures, user interface and test planning. Edexcel expects a modular design, so show a structure chart or class diagram that decomposes the system into manageable components. For key algorithms (searching, sorting, report generation), include pseudocode or flowcharts that demonstrate structured English and efficient solutions. Database design requires an entity-relationship diagram with a normalised schema down to third normal form.
设计部分必须覆盖整体系统架构、算法、数据结构、用户界面以及测试计划。Edexcel 期待模块化设计，因此要用结构图或类图将系统分解为可管理的组件。对于关键算法（搜索、排序、报告生成），要包含展示结构化英语和高效解的伪代码或流程图。数据库设计需包含实体关系图以及满足第三范式的规范化模式。
- UI: wireframes or mock-ups for each screen, showing navigation paths.
- 用户界面：每个界面的线框图或模型，展示导航路径。
- Data structures: justify choices like array vs. linked list, dictionary vs. tree.
- 数据结构：论证如数组之于链表、字典之于树的选用理由。
- Design a comprehensive test plan with normal, boundary and erroneous data at this stage.
- 在设计阶段就设计全面的测试计划，含有正常、边界和错误数据。
5. Development: Evidence of Technical Competence | 开发：技术能力的证据
The development and testing section carries the highest marks. You must present a chronological, annotated log of your coding process. Do not just paste thousands of lines of code; extract small, critical snippets that demonstrate advanced techniques. Show how you built the program iteratively, explaining why you chose specific constructs, libraries or paradigms. Evidence may include screenshots of the IDE, annotated code listings, and explanations of debugging and refactoring decisions.
开发与测试板块分值最高。你必须展示一份带注释的、按时间顺序的编码过程日志。不要直接粘贴数千行代码；而是摘取能展现高阶技巧的关键代码段。展示你是如何迭代构建程序的，并解释为何选用特定语句结构、库或范式。证据可包括集成开发环境截图、带注释的代码列表，以及对调试与重构决策的解释。
- Demonstrate advanced skills: parameterised SQL, recursion, event-driven programming, complexity analysis.
- 展现高阶技能：参数化 SQL、递归、事件驱动编程、复杂度分析。
- Use version control (e.g., Git) and embed evidence of branching and commits.
- 使用版本控制（如 Git），并嵌入分支与提交的证据。
- Show how you managed input validation and prevented SQL injection or buffer overflows.
- 展示如何实现输入验证并防御 SQL 注入或缓冲区溢出。
6. Iterative Development and Agile Practices | 迭代开发与敏捷实践
While the NEA is individual, adopting an agile mindset strengthens your narrative. Organise your log into sprints or phases, each ending with stakeholder feedback. Reflect on how that feedback led to requirement changes or design tweaks. This spiral of prototype–test–refine demonstrates genuine user-centred design and earns high marks under the evaluation criteria that reward continuous improvement.
尽管 NEA 是个人项目，采用敏捷思维能强化你的叙事。将开发日志组织为多个冲刺或阶段，每个阶段以利益相关者反馈收尾。反思这些反馈如何引发需求变更或设计微调。这种“原型—测试—精炼”的螺旋循环展示了真正的以用户为中心的设计，并在奖励持续改进的评价指标下赢取高分。
- Include dated feedback records (emails, meeting notes) and your response to each point.
- 附上注明日期的反馈记录（邮件、会议笔记）以及你对每点的回应。
- Use a burn-down chart or task board to visualise progress and scope management.
- 使用燃尽图或任务看板来可视化进度与范围管理。
- Explicitly mention where you followed MVC, singleton or other patterns to structure code.
- 明确指出你在何处遵循了 MVC、单例或其他模式来结构化代码。
7. Comprehensive Testing Strategy | 全面的测试策略
Testing is not just a final checkbox; it is woven throughout the project. Present unit tests for individual functions, integration tests for module interactions, and user acceptance testing with your stakeholder. Use a traceability matrix linking tests to requirements. For each test, show the input, expected outcome, actual outcome, and a screenshot as proof. When tests fail, explain your debugging process and the fix, closing the loop.
测试不只是一个最终勾选项；它贯穿整个项目。要展示针对单个函数的单元测试、针对模块交互的集成测试，以及与利益相关者进行的用户验收测试。使用需求追溯矩阵将测试与需求关联。对于每项测试，展示输入、预期结果、实际结果以及作为证据的截图。当测试失败时，解释你的调试过程与修复方案，形成闭环。
- Include boundary testing (max/min, empty lists, null) and erroneous data tests.
- 包含边界测试（最大值/最小值、空列表、空值）与错误数据测试。
- Test on different hardware/OS if portability is a stated requirement.
- 若可移植性是提出的需求之一，则在不同硬件/操作系统上测试。
- Quantify performance: measure response time for sorting large datasets or database queries.
- 量化性能：测量对大数据集排序或执行数据库查询的响应时间。
8. Evaluation: Honest Reflection on Success and Limitations | 评估：对成功与局限的诚实反思
Evaluation demands a structured, critical appraisal of the whole project. Revisit each objective from the analysis and state whether it was met, partially met or not met, with evidence. Discuss the usability feedback from your client and any unplanned features that emerged. Reflect on personal skill development and the lessons learned about project management. Crucially, identify realistic improvements you would make with more time or different tools.
评估要求对整个项目进行结构化、批判性的审视。回顾分析阶段设定的每个目标，陈述其是否达成、部分达成或未达成，并附上证据。讨论来自客户的可用性反馈，以及任何未曾计划但实现的功能。反思个人技能发展以及项目管理的经验教训。至关重要的一点是，要指出在拥有更多时间或不同工具的情况下会做出的现实改进。
- Use direct quotes from your stakeholder to validate satisfaction.
- 引用利益相关者的原话来佐证满意度。
- Compare alternative algorithms or data structures you considered but didn't use.
- 比较你曾考虑但未使用的替代算法或数据结构。
- Comment on code maintainability, efficiency and readability with concrete examples.
- 用具体实例评述代码的可维护性、效率和可读性。
9. Technical Documentation and Report Polish | 技术文档与报告润色
A professional report has a title page, table of contents, consistent headers, captioned figures and a bibliography citing sources (including stakeholder interviews, online tutorials and reference books). All code must be neatly formatted in a monospaced font, with syntax highlighting where possible. Use appendices for full code listings, extended test logs or lengthy raw data, keeping the main body concise. The writing style should be technical yet clear, assuming an examiner with A Level knowledge.
一份专业的报告包含封面、目录、统一标题、带图注的图表以及列出来源（包括利益相关者访谈、在线教程和参考书）的参考书目。所有代码必须用等宽字体整洁排版，尽可能附上语法高亮。用附录存放完整代码清单、扩展测试日志或冗长的原始数据，保持正文简洁。写作风格应技术化但清晰，假定读者是具备 A Level 知识水平的审核员。
- Run a spell/grammar check and ensure page numbers and cross-references are correct.
- 进行拼写/语法检查，确保页码与交叉引用正确无误。
- PDF submission must not exceed any file size limit; compress images wisely.
- 提交的 PDF 不得超出文件大小限制；妥善压缩图片。
- Ask a peer to review the report for clarity and logical flow before submission.
- 提交前请同学审阅报告的清晰度与逻辑流畅性。
10. Meeting the Mark Scheme and Avoiding Common Pitfalls | 紧扣评分标准与规避常见陷阱
The difference between a B and an A* often lies in alignment with the mark scheme. For high marks, analysis must show a 'wide range of stakeholders’ perspectives' and design must include 'full justification of all major decisions'. In development, avoid a simple linear narrative; show setbacks and how you overcame them. In evaluation, use the client's perspective to drive a nuanced discussion rather than a bland 'it works well'. Never fabricate stakeholder feedback — moderators can detect inconsistencies.
B 级与 A* 级的差距往往在于与评分标准的贴合度。要得高分，分析必须展现“广泛的利益相关者视角”；设计必须包含“对所有主要决策的充分论证”。在开发部分，避免简单的线性叙事；要展现挫折及你如何克服它们。在评估部分，运用客户视角推动有深度的讨论，而非泛泛而谈的“它运行良好”。绝不可捏造利益相关者反馈——审核员能够察觉不一致之处。
- Common mistakes: too much description, not enough justification; missing test evidence for boundary conditions.
- 常见错误：描述过多而论证不足；缺少边界条件的测试证据。
- Unrealistic project scope that cannot be completed in the allocated 60 guided learning hours.
- 项目范围不切实际，无法在分配的 60 导师指导学时内完成。
- Poor time management: starting coding before analysis is complete, or leaving documentation to the last week.
- 时间管理不佳：分析未完成就开始编码，或者把文档拖到最后一周。
11. Upholding Academic Integrity | 恪守学术诚信
All work must be your own. It is acceptable to use libraries and frameworks, but you must acknowledge them and the core functionality must be your original code. Clearly label any auto-generated code (e.g., from an IDE wizard) and justify its inclusion. If you adapt algorithms from textbooks or online sources, cite them and explain your adaptations. Plagiarism in the NEA, including collusion or using AI-generated code without substantial modification, is severely penalised.
所有工作必须出自本人。使用库和框架是可以的，但必须予以声明，且核心功能须为你原创的代码。清楚标注任何自动生成的代码（如来自 IDE 向导），并论证其纳入的合理性。如果改编了教材或在线来源的算法，务必引用并解释你的修改。NEA 中的抄袭——包括共谋或未经实质修改而使用 AI 生成代码——将受到严厉处罚。
- Keep a clear record of sources in a working bibliography from day one.
- 从第一天起就在工作参考书目中清晰记录来源。
- If you collaborate on research, state the nature and extent of collaboration in the report.
- 如果在调研中合作，须在报告中说明合作的性质与程度。
- Use your teacher as a supervisor: regular check-ins ensure you stay on track and understand the rules.
- 把老师当作导师：定期检查能确保你不偏离方向并理解规则。
12. Final Checklist Before Submission | 提交前的最终核对清单
Before compressing your project into the final PDF, verify that every assessment objective is addressed. Check that all diagrams are legible and that no evidence is missing (e.g., a clear link between a test log entry and a screenshot). Ensure the program runs on a standard school computer with no special dependencies uninstalled. Prepare a README file with clear compilation/execution instructions. Finally, take a deep breath and celebrate the completion of a major intellectual endeavour.
在将项目压缩为最终 PDF 之前，核实每个评估目标都已涵盖。检查所有图表是否清晰可读，确保证据无遗漏（例如，测试日志条目与截图的明确关联）。确保程序在标准学校计算机上可运行，无需安装特殊的未安装依赖。准备一份包含清晰编译/执行说明的 README 文件。最后，深呼吸，为这项重大智力工程的完成而庆祝。
- Video evidence of the running program is strongly recommended to avoid moderation issues.
- 强烈建议提供程序运行的视频证据，以避免审核问题。
- Double-check file naming conventions required by the exam board.
- 再次核对考试局要求的文件命名规范。
- Keep a backup copy and submit on time — late submissions can be heavily penalised.
- 保留一份备份并按时提交——迟交可能被严重扣分。
Published by TutorHao | Computer Science Revision Series | aleveler.com
更多咨询请联系16621398022（同微信）
或截图后用「扫一扫 → 相册」选择本图