📚 Year 11 WJEC Computer Science: Key Points for the Practical Assessment | 11年级WJEC计算机科学：实践考核要点
The WJEC GCSE Computer Science qualification includes a crucial practical assessment, known as Unit 3: Software Development Project. This non-examined assessment (NEA) gives you the opportunity to demonstrate your programming skills by solving a realistic problem over approximately 20 hours of supervised time. Success hinges not only on writing working code, but on following a systematic development process, producing clear documentation, and providing robust evidence of testing and evaluation. Mastering the key points outlined below will help you secure high marks and build a solid foundation for further study.
WJEC GCSE计算机科学资格包含一个关键的实践考核，即单元3：软件开发项目。这项非考试评估(NEA)让你有机会在大约20小时的监督时间内，通过解决一个现实问题来展示你的编程技能。成功不仅取决于编写可运行的代码，还取决于遵循系统化的开发流程、撰写清晰的文档，以及提供扎实的测试与评估证据。掌握以下要点将帮助你获得高分，并为后续学习打下坚实基础。
1. Understanding the Assessment Structure | 理解考核结构
Unit 3 is internally assessed by your teacher and externally moderated by WJEC. It is worth 40 marks, split across four assessment objectives: Analysis (5 marks), Design (10 marks), Development (15 marks), and Testing & Evaluation (10 marks). The work must be your own, produced under controlled conditions, and submitted as a single report containing all evidence alongside your program code. You will be given a broad scenario from which you must derive a specific, manageable problem to solve.
单元3由你的老师内部评估，并由WJEC外部审核。它共占40分，分为四个评估目标：分析(5分)、设计(10分)、开发(15分)以及测试与评估(10分)。作品必须是你自己的，在受控条件下完成，并作为一份包含所有证据和程序代码的报告提交。你将获得一个宽泛的场景，必须从中提取出一个具体、可管理的问题来解决。
It is essential to check the latest specification and administrative guide from WJEC, as rules on permitted resources, word limits, and submission formats may change. You must sign a declaration of academic honesty, and your teacher will authenticate your work. Any code or ideas taken from external sources must be clearly cited, or it could be considered malpractice.
务必查看WJEC最新的规格说明和行政指南，因为允许使用的资源、字数限制和提交格式的规则可能会变化。你必须签署学术诚信声明，你的老师将验证你的作品。任何来自外部来源的代码或想法都必须清楚引用，否则可能被视为违规。
2. Selecting a Rich Project Scenario | 选择丰富的项目场景
Your teacher will provide a scenario, such as a 'learning game', 'booking system', or 'data analysis tool'. Avoid the temptation to pick the simplest option; choose one that allows you to demonstrate a range of skills. A good project idea includes opportunities for file handling, meaningful data structures (arrays, dictionaries), iteration, conditionals, data validation, string manipulation, and a user-friendly interface (though this can be text-based). The mark scheme rewards complexity and appropriate use of techniques.
你的老师会提供一个场景，例如"学习游戏"、"预订系统"或"数据分析工具"。避免选择最简单选项的诱惑；要选择一个能让你展示多种技能的选题。一个好的项目想法应包括文件处理、有意义的数据结构（数组、字典）、迭代、条件判断、数据验证、字符串操作以及用户友好的界面（尽管可以是基于文本的）等机会。评分方案奖励复杂性和技术的恰当运用。
Ensure the scope is achievable within the 20-hour limit. A sprawling, half-finished project scores less than a focused, fully functional one. Discuss your idea with your teacher before committing, and break it down into core features and optional enhancements. Focus on delivering a polished core product, then add extra features if time permits.
确保范围可在20小时限制内完成。一个铺得太开、半途而废的项目，分数不如一个专注且完全可运行的项目。决定之前先与老师讨论你的想法，并将其分解为核心功能和可选增强功能。专注于交付一个完善的核心产品，如果时间允许再添加额外功能。
3. Analysis: Defining the Problem Clearly | 分析：清晰定义问题
The analysis section requires you to interpret the given scenario, identify stakeholders, state specific objectives, and outline the boundary of your system. Write a concise problem statement that explains what your program will do and what it will not do. Use bullet points to list functional requirements (e.g., "register a new user", "calculate average score") and non-functional requirements (e.g., "respond within 2 seconds", "run on Windows"). All requirements must be testable.
分析部分要求你解释给定的场景，识别利益相关者，陈述具体目标，并概述系统的边界。撰写一份简洁的问题陈述，说明你的程序将做什么和不做什么。使用项目符号列出功能性需求（例如"注册新用户"、"计算平均分"）和非功能性需求（例如"2秒内响应"、"在Windows上运行"）。所有需求都必须是可测试的。
A clear analysis also includes a description of the target user group and a table that links each requirement to a success criterion. For instance, a requirement "validate email address" might have the success criterion "system rejects emails missing '@' symbol". This traceability will later simplify your testing. Keep the analysis free of solution details; focus on what, not how.
清晰的分析还应包括对目标用户群的描述，以及一个将每项需求与成功标准联系起来的表格。例如，需求"验证电子邮件地址"的成功标准可以是"系统拒绝缺少'@'符号的电子邮件"。这种可追溯性将在后续简化你的测试。分析中不要包含解决方案的细节；专注于"做什么"，而非"怎么做"。
4. Design: Flowcharts, Pseudocode, and Mock-ups | 设计：流程图、伪代码与模型
Design accounts for a quarter of the marks, so invest time here. Create a high-level system flowchart (or a structure diagram) showing how the main modules interact. For each non-trivial module, provide detailed pseudocode using consistent notation (e.g., IF score >= 80 THEN). Your pseudocode must be logic-rich, demonstrating sequence, selection, and iteration. Include comments to explain the purpose of each section.
设计占四分之一的分数，因此要投入时间。创建一个高层次的系统流程图（或结构图），展示主模块如何交互。对于每一个非平凡模块，提供使用一致符号的详细伪代码（例如 IF score >= 80 THEN）。你的伪代码必须逻辑丰富，展示顺序、选择和迭代。添加注释以解释每个部分的目的。
If your program has a user interface, sketch wireframes or text-based menu layouts. Label all input fields, output areas, and navigation pathways. Clearly show how the user moves from one screen to another. The design must align with the analysis; each functional requirement should have a corresponding module or algorithm. A proper data flow diagram (Level 0 DFD) can also demonstrate how data moves between processes, stores, and external entities.
如果你的程序有用户界面，画出线框图或基于文本的菜单布局草图。标注所有输入字段、输出区域和导航路径。清晰展示用户如何从一个屏幕移动到另一个屏幕。设计必须与分析保持一致；每项功能需求都应有对应的模块或算法。适当的数据流图（0级DFD）还能展示数据如何在处理过程、存储和外部实体之间流动。
5. Development: Coding Conventions and Evidence | 开发：编码规范与证据
The development section is where you write the actual program. You are expected to use appropriate programming constructs, such as variables, constants, local and global variables, lists, subroutines (procedures/functions), parameter passing, and exception handling. Use meaningful variable names (e.g., player_score not a) and comment frequently to explain the logic. Always include a header block stating the purpose, author, and date at the top of each file.
开发部分是你编写实际程序的地方。你期望使用恰当的编程构造，如变量、常量、局部和全局变量、列表、子程序（过程/函数）、参数传递和异常处理。使用有意义的变量名（如 player_score 而非 a），并经常添加注释以解释逻辑。每个文件的顶部始终包含一个声明目的、作者和日期的标题块。
You must submit the complete source code, but more importantly, you need to provide annotated screenshots or code snippets within your report to highlight specific techniques. For example, show a screen capture of your file-handling routine and explain how it reads and writes data. The examiner wants to see your understanding, not just the finished product. Maintain a development log noting key decisions, bugs fixed, and changes from the original design.
你必须提交完整的源代码，但更重要的是，你需要在报告中提供带注释的屏幕截图或代码片段，以突出特定技巧。例如，展示文件处理例程的屏幕截图，并解释其如何读写数据。考官希望看到你的理解，而不仅仅是成品。维护一份开发日志，记录关键决策、修复的bug以及与原设计的变更。
6. Testing: Creating a Comprehensive Test Plan | 测试：制定全面的测试计划
Begin by designing a test table before you write any code. The table should include a test ID, description, test data (normal, boundary, invalid), expected outcome, actual outcome, and a pass/fail column. You must use a wide range of test data: typical values, values at the limits (e.g., maximum string length), and deliberately wrong inputs to ensure robust validation. Every functional requirement must be tested at least once.
在编写任何代码之前，先设计一个测试表。该表应包括测试ID、描述、测试数据（正常、边界、无效）、预期结果、实际结果和通过/失败列。你必须使用广泛的测试数据：典型值、极限值（如最大字符串长度）以及故意错误输入，以确保稳健验证。每项功能需求至少测试一次。
Execute your tests and document the outcomes faithfully. If a test fails, do not delete it; instead, explain why it failed, what corrective action you took, and provide evidence of a re-test. Include screenshots of test runs, error messages, and corrected output. The evaluation of testing is also vital: summarise how well your system meets the success criteria and mention any unresolved issues. This honest reflection earns higher marks than a superficial "everything works" claim.
忠实地执行测试并记录结果。如果某个测试失败，不要将其删除；相反，解释它为何失败，你采取了什么纠正措施，并提供重新测试的证据。包含测试运行、错误消息和修正后输出的屏幕截图。测试的评估也至关重要：总结你的系统在多大程度上满足了成功标准，并提及任何未解决的问题。这种诚实的反思比肤浅的"一切正常"能获得更高分数。
7. Evaluation: Objective Reflection and Improvements | 评估：客观反思与改进
The final evaluation should discuss the project’s overall success, comparing the final product against the original requirements and design objectives. Identify at least three strengths and three weaknesses, supporting each with specific evidence. For every weakness, propose a realistic improvement that you could implement with more time or different tools. Avoid vague statements like "I could have added more features" and instead be precise, e.g., "I would replace linear search with binary search in the high-score module to improve efficiency when the dataset grows."
最终评估应讨论项目的整体成功，将最终产品与原始需求和设计目标进行比较。至少指出三点优点和三点缺点，并用具体证据支撑每一点。对于每一个缺点，提出一个在更多时间或有不同工具的情况下可以实现的现实改进。避免诸如"我可以添加更多功能"这样模糊的陈述，而要精确，例如："我会在高分模块中将线性搜索替换为二分搜索，以在处理更大数据集时提高效率。"
Consider the user experience. Did your program meet the needs of the target audience? You might quote feedback from a peer tester. Also reflect on your personal learning: what skills did you develop, and what would you do differently next time? The evaluation should demonstrate a mature understanding of the software development lifecycle and your own performance within it.
考虑用户体验。你的程序是否满足了目标受众的需求？你可以引用同行测试者的反馈。还要反思你的个人学习：你发展了哪些技能，下次你会有什么不同的做法？评估应展示出你对软件开发生命周期以及自身在其中的表现有成熟的理解。
8. Assembling the Final Report: Evidence and Format | 整理最终报告：证据与格式
Your report is the primary evidence for moderation. It typically contains: a title page, table of contents, analysis, design (flowcharts, pseudocode, wireframes), development (annotated code extracts, development log), testing (test plan, test outcomes, evidence), evaluation, and appendices (full code listing). Use consistent formatting, clear headings, page numbers, and a professional tone throughout. Check that all diagrams are labelled and readable.
你的报告是审核的主要证据。它通常包含：标题页、目录、分析、设计（流程图、伪代码、线框图）、开发（带注释的代码摘录、开发日志）、测试（测试计划、测试结果、证据）、评估和附录（完整代码清单）。全文使用一致的格式、清晰的小标题、页码和专业的语气。检查所有图表是否都有标注且清晰可读。
A common mistake is submitting a massive block of uncommented code without explanation. Instead, integrate your code as small, focused snippets within the development section, each accompanied by a narrative that shows your understanding. The complete source code should be submitted separately, often as a zipped folder, but your report must still stand alone as a coherent document. Verify the submission requirements with your teacher to avoid last-minute panic.
一个常见错误是提交一大块没有注释的代码而不加解释。反过来，将代码作为小型、专注的片段整合到开发部分中，每个片段都附有说明，以展示你的理解。完整的源代码应单独提交，通常为一个压缩文件夹，但你的报告必须仍然能够作为一份连贯的文档独立存在。与你的老师确认提交要求，以避免最后时刻手忙脚乱。
9. Managing Your Time and Resources | 管理时间与资源
Plan your 20 hours carefully. Allocate roughly: 2 hours for analysis and planning, 4 hours for design, 8 hours for coding and development logging, 4 hours for testing and reporting, and 2 hours for evaluation and final checks. Set mini-deadlines for each phase and keep a simple Gantt chart in your progress log. Stick to the plan, but be flexible if a technical difficulty consumes extra time—adjust by trimming non-essential features.
仔细规划你的20小时。大致分配为：分析和计划2小时，设计4小时，编码和开发日志8小时，测试和报告4小时，评估和最终检查2小时。为每个阶段设定小截止日期，并在进度日志中保持一个简单的甘特图。遵守计划，但如果技术困难消耗了额外时间，则要灵活——通过删减非必要功能来调整。
Use your supervised sessions efficiently. Before coding, sketch your algorithms on paper. Save regular backups of your code using version numbers (e.g., project_v1.2.py). When you hit a roadblock, ask your teacher for guidance—they can help you debug or clarify requirements, but they cannot write code for you. Controlled conditions mean you must not bring in pre-written code or access online forums; familiarise yourself with the rules to protect your assessment.
高效地利用你的受控课时。在编码之前，先在纸上草拟算法。使用版本号定期备份代码（例如 project_v1.2.py）。遇到困难时，向老师寻求指导——他们能帮你调试或澄清需求，但不能替你写代码。受控条件意味着你不能带入预先写好的代码或访问在线论坛；熟悉规则以保护你的评估。
10. Common Pitfalls and How to Avoid Them | 常见陷阱及其避免方法
A frequent issue is overcomplicating the user interface while neglecting core logic. Remember that a neat, text-based menu system with robust input validation scores much higher than a messy graphical interface that crashes. Start with core functionality, get it working perfectly, then layer on extra features only if you are confident. Also, do not leave testing until the final hour; integrate testing from the very first function you write.
一个常见问题是过分复杂化用户界面而忽视核心逻辑。请记住，一个整洁、基于文本的菜单系统加上稳健的输入验证，其得分远高于一个会崩溃的凌乱图形界面。从核心功能开始，让它完美运行，然后仅在你有信心时才添加额外功能。另外，不要把测试留到最后一小时；从你编写的第一个函数起就集成测试。
Another trap is poor evidence. Skipping screenshots or failing to annotate them means the moderator cannot see your thought process. Every time you demonstrate a programming technique (e.g., using a 2D array, reading from a CSV file, implementing a bubble sort), capture it and comment on its role. Finally, plagiarism is a serious offence. Even reusing small snippets from the internet without attribution can lead to disqualification. If you use external code, explicitly cite the source and explain what you modified—this often turns a potential issue into a positive reflection of research skills.
另一个陷阱是证据不足。跳过屏幕截图或不加注释，意味着审核员看不到你的思维过程。每当你展示一项编程技巧（例如使用二维数组、从CSV文件读取、实现冒泡排序），都要截取它并评论其作用。最后，抄袭是严重的违规行为。即使是从互联网上借用小型代码片段而不标明出处，也可能导致取消资格。如果你使用了外部代码，要明确引用来源并解释你做了哪些修改——这通常能将潜在问题转化为对研究技能的积极体现。
| Objective | 目标 | Marks | 分值 | Focus | 重点 |
|---|---|---|
| Analysis | 5 | Clear problem, requirements, success criteria |
| Design | 10 | Decomposition, algorithms, UI design |
| Development | 15 | Functional program, use of constructs, evidence |
| Testing & Evaluation | 10 | Test plan, data, outcomes, reflection |
11. Grading Insights and Examiner Expectations | 评分洞见与考官期望
Examiners look for a well-structured, logical solution that matches the problem. High marks in Development come from independently applying a variety of techniques correctly—such as data validation, modularisation, and external file storage. In Testing, a table with 15-20 tests covering normal, boundary, and erroneous data is typical of a top band. For Evaluation, a candidate who can critically assess their own work and suggest sophisticated improvements (e.g., using an SQL database instead of text files) often reaches the top mark.
考官期望一个结构良好、逻辑清晰的解决方案，与问题紧密匹配。开发部分的高分源自独立、正确地运用多种技术——例如数据验证、模块化和外部文件存储。在测试部分，一个包含15-20个测试、涵盖正常、边界和错误数据的表格通常是高分段的典型特征。在评估部分，能够批判性地评价自己的作品并提出复杂改进建议（例如使用SQL数据库替代文本文件）的考生往往能拿到满分。
Remember that the project is not just about coding; it is about following a professional process. The moderator can only award marks for what is evidenced in your report. Even if your code is brilliant, if you do not explicitly describe the design decisions, the moderator cannot guess them. Therefore, treat the report as equally important as the program itself. Review the marking criteria regularly as you progress—this keeps your effort targeted precisely on earning maximum marks.
请记住，项目不仅仅是关于编码；它关乎遵循一个专业的过程。审核员只能根据你报告中记录的证据来给分。即使你的代码非常出色，如果你没有明确描述设计决策，审核员也无法猜测。因此，将报告视为与程序本身同等重要。随着进度推进，定期回顾评分标准——这能让你的努力精准地瞄准最高分数。
12. Final Preparation and Submission Checklist | 最终准备与提交清单
In the last session, methodically go through this checklist: Have you included all sections (analysis, design, development, testing, evaluation)? Is every design diagram properly referenced in the text? Are all code screenshots annotated with the technique being demonstrated? Does your test plan cover every functional requirement? Have you run a spell check and ensured consistent headings? Is your full source code submitted as a separate, runnable file? Have you signed the authentication form?
在最后一个课时，有条理地核对这份清单：你是否包含了所有部分（分析、设计、开发、测试、评估）？文中是否恰当地引用了每张设计图？所有代码屏幕截图是否都标注了正在展示的技术？你的测试计划是否覆盖了每项功能需求？你是否运行了拼写检查并确保标题一致？完整的源代码是否作为独立、可运行的文件提交？你是否在认证表上签字？
One final piece of advice: save your work in multiple locations. Use your school network, a cloud storage account (if permitted), and a USB drive to prevent data loss. On submission day, allow extra time to upload or print the report if required. Leaving a mature, well-evidenced project behind you is not only a path to a top GCSE grade but also excellent preparation for A Level Computer Science and beyond.
最后一条建议：将你的成果保存在多个位置。使用学校网络、云存储账户（如允许）和U盘以防止数据丢失。在提交日，预留额外时间以上传或打印报告（如有需要）。留下一份成熟、证据充分的项目，不仅能通向GCSE高分，也是为A Level计算机科学及更高阶段学习的绝佳准备。
Published by TutorHao | Computer Science Revision Series | aleveler.com
更多咨询请联系16621398022（同微信）
或截图后用「扫一扫 → 相册」选择本图