📚 WJEC Year 13 Computer Science: Practical Assessment Essentials | WJEC 13年级计算机：实验/实践考核要点
For WJEC A-Level Computer Science students in Year 13, the practical component—specifically Unit 5: Programmed Solution to a Problem—represents a substantial and decisive element of the final grade. This Non-Examined Assessment (NEA) requires candidates to independently analyse, design, develop, test, and evaluate a software solution to a genuine problem, demonstrating not only programming proficiency but also the systematic application of the software development lifecycle. Success hinges on meticulous planning, robust documentation, and a clear understanding of what WJEC examiners are looking for at each stage of the project.
对于 WJEC A-Level 计算机科学 13 年级的学生来说，实践部分——具体而言是单元五（Unit 5）：编程解决实际问题——占据了最终成绩中相当重要且具有决定性的一部分。这项非考试评估（NEA）要求考生独立分析、设计、开发、测试并评估一个针对真实问题的软件解决方案，不仅要展示编程能力，还要体现软件开发生命周期的系统化应用。成功的关键在于周密的规划、扎实的文档编写，以及对 WJEC 考官在项目每个阶段所关注要点的清晰理解。
1. Understanding the Structure of Unit 5 | 理解单元五的结构
Unit 5 is the A2 practical coursework module, carrying significant weight in the overall A-Level qualification. Unlike AS Unit 2, which is an on-screen practical examination under timed conditions, Unit 5 is an extended independent project conducted over several months. Candidates must produce a complete software solution along with comprehensive written documentation covering every phase of the development process. The project is internally assessed by teachers and externally moderated by WJEC, meaning consistency with the mark scheme is absolutely critical throughout.
单元五是 A2 阶段的实践课程作业模块，在整个 A-Level 资格认证中占有重要权重。与 AS 阶段的单元二（限时上机实践考试）不同，单元五是一个持续数月、需要独立完成的大型项目。考生必须完成一个完整的软件解决方案，并附上涵盖开发过程每个阶段的详尽书面文档。该项目由教师内部评分、WJEC 外部复核，因此整个过程中与评分标准保持一致至关重要。
- Assessment weighting: Unit 5 accounts for 20% of the full A-Level qualification
- Word count expectation: The written report typically ranges between 8,000 and 12,000 words of substantive content
- Mark allocation: The project is marked out of 100 raw marks across multiple assessment objectives
- Programming language: Candidates may use any suitable high-level language; Python, C#, Java, and VB.NET are common choices
- 评估权重：单元五占完整 A-Level 资格的 20%
- 字数预期：书面报告通常包含 8,000 到 12,000 字的实质性内容
- 分数分配：项目满分 100 原始分，涵盖多个评估目标
- 编程语言：考生可使用任何合适的高级语言；Python、C#、Java 和 VB.NET 是常见选择
2. Selecting a Suitable Project Problem | 选择合适的项目问题
The single most consequential decision in Unit 5 is the choice of problem to solve. WJEC explicitly requires that the problem be genuine—ideally sourced from a real end-user with authentic needs. Hypothetical or textbook-style problems severely limit the depth of analysis and stakeholder engagement possible, often resulting in lower marks. The best projects arise from conversations with local businesses, school departments, family members running small enterprises, or community organisations where a tangible software need exists.
单元五中最具决定性的一个决策就是选择要解决的问题。WJEC 明确要求问题必须是真实的——理想情况下应来自有实际需求的真实终端用户。假设性或教科书式的问题严重限制了分析的深度和利益相关者互动的可能性，通常会导致较低的分数。最佳项目往往源于与当地企业、学校部门、经营小生意的家庭成员或社区组织的沟通，在这些场景中存在切实的软件需求。
- Genuine end-user requirement: The problem must exist independently of the coursework; someone should genuinely benefit from the solution
- Appropriate complexity: The solution should require meaningful algorithmic thinking—database operations, file handling, searching, sorting, or data processing beyond trivial CRUD operations
- Feasibility: The project must be completable within the available timeframe with the candidate's current skills
- Scope for advanced techniques: Look for opportunities to incorporate object-oriented programming, recursion, data structures, or API integration
- 真实的终端用户需求：问题必须独立于课程作业而存在；确实有人能从解决方案中受益
- 适当的复杂度：解决方案应需要有意义算法思维——数据库操作、文件处理、搜索、排序或超越简单 CRUD 操作的数据处理
- 可行性：项目必须在可用时间内以考生现有技能完成
- 高级技术的空间：寻找引入面向对象编程、递归、数据结构或 API 集成的机会
3. The Analysis Phase: Defining Requirements Rigorously | 分析阶段：严谨地定义需求
Analysis forms the foundation upon which the entire project rests. WJEC expects candidates to demonstrate systematic investigation of the problem domain, clear elicitation of user requirements, and precise specification of what the software must accomplish. This phase should begin with a detailed interview or questionnaire with the end-user, producing qualitative data that can be translated into functional and non-functional requirements. The analysis must justify why a software solution is appropriate and what existing approaches lack.
分析阶段构成了整个项目的基础。WJEC 期望考生展示对问题域的系统化调研、对用户需求的清晰获取，以及软件必须达成目标的精确规格说明。这一阶段应从与终端用户的详细访谈或问卷调查开始，生成可转化为功能性和非功能性需求的定性数据。分析必须论证为何软件解决方案是合适的，以及现有方法存在哪些不足。
| Analysis Deliverable | 分析交付物 | Key Content Expected | 预期关键内容 |
|---|---|
| Problem Statement | 问题陈述 | Clear description of the current situation, the problems it causes, and who is affected |
| Stakeholder Analysis | 利益相关者分析 | Identification of all users and their specific needs, roles, and technical ability |
| Functional Requirements | 功能性需求 | Specific, measurable, and testable statements of what the system must do |
| Non-Functional Requirements | 非功能性需求 | Performance, security, usability, scalability, and platform constraints |
| Data Flow Diagrams | 数据流图 | Visual representation of how data moves through the current and proposed systems |
WJEC rewards candidates who produce a thorough requirements specification that is explicitly linked to the end-user's stated needs. Every functional requirement should be traceable back to something the stakeholder actually said during the initial investigation, and this traceability should be clearly documented.
WJEC 对那些能够提供详尽需求规格说明、并明确与终端用户所述需求相关联的考生给予奖励。每项功能性需求都应可追溯到利益相关者在初始调查中实际表达的内容，这种可追溯性应在文档中清晰呈现。
4. Design: From Requirements to Technical Blueprint | 设计：从需求到技术蓝图
The design phase translates the analysis findings into a concrete technical plan. This is where WJEC examiners look for evidence of structured thinking, appropriate use of design notation, and genuine consideration of alternatives. Design must cover algorithms, data structures, user interface, and the overall architecture of the solution. Candidates who simply describe what they built rather than showing deliberate design decisions with justified rationale will struggle to achieve top marks in this section.
设计阶段将分析结果转化为具体的技术方案。WJEC 考官在此寻找结构化思维的证据、设计符号的恰当使用，以及对替代方案的切实考量。设计必须涵盖算法、数据结构、用户界面以及解决方案的整体架构。仅仅描述自己构建了什么、而不展示有充分理由支撑的深思熟虑设计决策的考生，将难以在这一部分获得高分。
- Algorithm design: Use pseudocode or flowcharts to specify key algorithms before coding begins; these should be detailed enough that another programmer could implement them
- Data structure design: Specify record structures, class diagrams, database schemas with entity-relationship diagrams, and justify choices such as array vs linked list or flat file vs relational database
- UI prototyping: Create wireframes or mock-ups and obtain end-user feedback on them, documenting how this feedback refined the design
- Modular decomposition: Break the system into logical modules with clearly defined interfaces, using structure charts or component diagrams
- 算法设计：在开始编码前用伪代码或流程图明确关键算法；这些应足够详细，使其他程序员能够据此实现
- 数据结构设计：明确记录结构、类图、带实体关系图的数据库模式，并论证诸如数组与链表、平面文件与关系数据库等选择
- UI 原型设计：创建线框图或模型并获取终端用户反馈，记录这些反馈如何完善了设计
- 模块分解：使用结构图或组件图将系统分解为具有清晰定义接口的逻辑模块
5. Development: Systematic Coding with Evidence | 开发：系统化编码并提供证据
The development section is not merely a code dump—it is a narrative of how the software was constructed, demonstrating technical competence and problem-solving. WJEC expects to see annotated code extracts showing key techniques, explanations of why particular approaches were chosen, and honest reflection on challenges encountered and overcome. Screenshots alone are insufficient; the candidate must explain what the code does, how it works, and why it was written that way. Evidence of iterative refinement and testing during development strengthens this section considerably.
开发部分不仅仅是代码堆砌——它是对软件如何构建的叙述，展示技术能力和问题解决过程。WJEC 期望看到带注释的代码摘录，展示关键技术，解释为何选择特定方法，并对遇到和克服的挑战进行诚实的反思。仅有截图是不够的；考生必须解释代码做什么、如何工作，以及为何以那种方式编写。开发过程中的迭代优化和测试证据能显著增强这一部分的说服力。
- Annotated code extracts: Select approximately 8-12 key segments that demonstrate a range of techniques; annotate each thoroughly
- Evidence of modular approach: Show how modules were developed and integrated, with clear interface definitions
- Problem-solving narrative: Document at least 2-3 significant challenges, the debugging process, and how solutions were devised
- Coding standards: Maintain consistent naming conventions, indentation, and commenting throughout
- Version evidence: If using version control, include evidence; otherwise, maintain dated backups showing progression
- 带注释的代码摘录：选择大约 8-12 个展示多种技术的关键片段；对每个片段进行详尽注释
- 模块化方法的证据：展示模块如何开发和集成，具有清晰的接口定义
- 问题解决叙述：记录至少 2-3 个重要挑战、调试过程以及解决方案是如何制定的
- 编码规范：全程保持一致的命名约定、缩进和注释
- 版本证据：如果使用版本控制，请附上证据；否则，保留标注日期的备份以展示进展
6. Testing: Beyond Superficial Validation | 测试：超越表面化的验证
Testing is one of the most heavily weighted sections in the WJEC mark scheme, yet it is frequently the weakest element in candidate submissions. A superficial table showing a few screenshots with 'it works' is wholly inadequate. WJEC demands a rigorous, structured testing strategy that includes test planning, test data justification, evidence of execution, and post-testing analysis. Tests must directly address every functional and non-functional requirement identified during analysis, and there must be evidence of both normal, boundary, and erroneous test cases.
测试是 WJEC 评分标准中权重最高的部分之一，但它往往是考生提交材料中最薄弱的环节。一张显示几张截图并标注"它有效"的肤浅表格是完全不够的。WJEC 要求严格、结构化的测试策略，包括测试计划、测试数据论证、执行证据和测试后分析。测试必须直接针对分析阶段确定的每项功能性和非功能性需求，并且必须有正常、边界和错误测试用例的证据。
- Test plan: A structured table listing test ID, requirement being tested, test description, test data with justification, expected result, actual result, and pass/fail status
- Test data types: Include normal (typical), boundary (edge values), and erroneous (invalid) data for each testable requirement; justify why each data value was chosen
- Cross-referencing: Every test must be traceable to a specific functional requirement identified earlier
- Re-testing evidence: When tests fail, show corrective action taken and successful re-test results
- End-user testing: Include evidence of the actual stakeholder using the system and providing structured feedback
- 测试计划：一个结构化的表格，列出测试 ID、被测试的需求、测试描述、带论证的测试数据、预期结果、实际结果和通过/失败状态
- 测试数据类型：为每个可测试的需求包含正常（典型）、边界（边缘值）和错误（无效）数据；论证为何选择每个数据值
- 交叉引用：每个测试必须可追溯到先前确定的特定功能性需求
- 重新测试证据：当测试失败时，展示采取的纠正措施和成功的重新测试结果
- 终端用户测试：包含实际利益相关者使用系统并提供结构化反馈的证据
7. Evaluation: Critical Reflection on the Complete Process | 评估：对整个过程的批判性反思
The evaluation section is where candidates demonstrate higher-order thinking by critically appraising their own work. This must go far beyond a simple 'the project was successful' statement. WJEC expects a balanced assessment that honestly identifies strengths and weaknesses, evaluates the solution against the original objectives and end-user feedback, and discusses what would be done differently with hindsight. The best evaluations reference specific evidence from testing and user feedback, rather than making vague assertions.
评估部分是考生通过批判性地审视自身工作来展示高阶思维的地方。这必须远远超越简单的"项目很成功"的陈述。WJEC 期望一个平衡的评估，诚实地指出优点和缺点，对照原始目标和终端用户反馈来评价解决方案，并讨论如果重新来做会有哪些不同。最佳评估会引用测试和用户反馈中的具体证据，而不是做出模糊的断言。
- Objective achievement: Systematically evaluate whether each functional and non-functional requirement was met, citing test evidence
- End-user satisfaction: Present and analyse structured feedback from the stakeholder; include direct quotes where appropriate
- Limitations acknowledged: Honestly identify what the system does not do well or what features were descoped
- Future enhancements: Propose realistic, technically justified improvements that could be made with additional time
- Personal learning: Reflect on skills developed, knowledge gained, and how the experience informs future practice
- 目标达成情况：系统评估每项功能性和非功能性需求是否得到满足，引用测试证据
- 终端用户满意度：呈现并分析来自利益相关者的结构化反馈；适当时包含直接引述
- 承认局限性：诚实地指出系统哪些方面做得不好，或者哪些功能被缩减了范围
- 未来改进：提出在额外时间下可实现、技术上有依据的现实改进方案
- 个人学习收获：反思发展的技能、获得的知识，以及这次经验如何指导未来的实践
8. Documentation Standards and Professional Presentation | 文档规范与专业呈现
The quality of written communication carries explicit marks in Unit 5, and poor presentation can undermine even technically excellent work. WJEC expects a professionally formatted report with consistent styling, clear section numbering, appropriate use of diagrams and screenshots, and a coherent narrative that guides the reader through the development journey. Spelling, grammar, and technical accuracy all contribute to the overall impression. Candidates should treat the report as a professional document that would be presentable to a client or employer.
书面沟通质量在单元五中有明确的分数，糟糕的呈现方式甚至可能削弱技术上出色的工作。WJEC 期望一份格式专业、风格一致、章节编号清晰、图示和截图使用得当、并具有引导读者了解开发历程的连贯叙述的报告。拼写、语法和技术准确性都会影响整体印象。考生应将报告视为一份可以向客户或雇主展示的专业文件。
- Consistent formatting: Use the same font, heading styles, and spacing throughout; create a table of contents with page numbers
- Diagram quality: All diagrams should be clear, correctly labelled, and created using appropriate software rather than hand-drawn
- Screenshot standards: Crop screenshots to show only relevant content; annotate them to highlight key features; ensure text is legible
- Referencing: Acknowledge any external resources, libraries, or code fragments not entirely your own work
- Appendices: Use appendices for full code listings, keeping the main body focused on annotated extracts
- 一致的格式：全文使用相同的字体、标题样式和间距；创建带页码的目录
- 图表质量：所有图表应清晰、标注正确，并使用适当软件创建而非手绘
- 截图标准：裁剪截图仅显示相关内容；加以注释以突出关键功能；确保文字清晰可读
- 参考文献：承认任何外部资源、库或非完全原创的代码片段
- 附录：将完整代码清单放在附录中，正文聚焦于带注释的摘录
9. Common Pitfalls That Cost Marks | 导致失分的常见陷阱
Year after year, WJEC examiner reports highlight recurring weaknesses that prevent otherwise capable candidates from achieving top marks. Awareness of these common pitfalls allows students to proactively avoid them. The most frequent issues include insufficient stakeholder engagement, testing that lacks rigour, design sections written retrospectively, and evaluations that are either entirely positive or lack specific evidence. Understanding these patterns is as important as knowing what to do right.
年复一年，WJEC 考官报告都会强调一些反复出现的弱点，这些弱点使本来有能力的考生无法获得最高分。了解这些常见陷阱可以让学生主动避免它们。最常见的问题包括利益相关者互动不足、测试缺乏严谨性、设计部分事后补写，以及评估要么完全正面要么缺乏具体证据。理解这些模式与知道如何正确操作同样重要。
- Retrospective design: Writing the design section after completing the code produces a sanitised, unrealistic account; genuine design thinking must precede implementation and include evidence of iteration
- Tokenistic testing: A handful of screenshots with 'works as expected' does not constitute rigorous testing; every requirement needs planned, justified, and evidenced testing
- Absent end-user: Projects without genuine stakeholder interaction throughout the process lack authenticity and limit the depth of analysis and evaluation possible
- Over-ambition: Attempting an excessively complex project that cannot be completed leads to incomplete documentation and missing evidence across multiple sections
- Insufficient algorithmic content: A project that is essentially a CRUD interface with a database offers limited scope for demonstrating computational thinking
- 事后补设计：在完成代码后再编写设计部分会产生一个经过粉饰、不真实的叙述；真正的设计思维必须先于实现，并包含迭代的证据
- 象征性测试：几张标注"按预期工作"的截图并不构成严格的测试；每个需求都需要有计划、有论证、有证据的测试
- 缺少终端用户：整个过程中没有真实利益相关者互动的项目缺乏真实性，限制了分析和评估的深度
- 过度雄心勃勃：尝试过于复杂而无法完成的项目，导致文档不完整、多个部分缺少证据
- 算法内容不足：本质上只是带数据库的 CRUD 界面的项目，展示计算思维的空间有限
10. Time Management and Project Planning | 时间管理与项目规划
Unit 5 is a marathon, not a sprint. WJEC expects the project to be conducted over an extended period, typically 6-9 months of Year 13. Effective time management is therefore a critical success factor. Candidates should establish a project timeline with clear milestones for each phase, build in buffer time for unexpected challenges, and maintain regular contact with their end-user. Falling behind in the early phases—particularly analysis and design—creates a cascade effect that compromises every subsequent section.
单元五是一场马拉松，而非短跑。WJEC 期望项目在一个较长的时期内进行，通常是 13 年级的 6 到 9 个月。因此，有效的时间管理是一个关键的成功因素。考生应建立一个项目时间表，为每个阶段设定清晰的里程碑，为意外挑战预留缓冲时间，并与终端用户保持定期联系。在早期阶段——特别是分析和设计阶段——落后会产生连锁效应，影响后续的每一个部分。
- Phase allocation: Analysis (15%), Design (15%), Development and testing (50%), Evaluation (15%), Final review and polish (5%) of total project time
- Regular milestones: Set weekly or fortnightly goals and review progress against them; involve the teacher in monitoring
- End-user diary: Maintain a log of all stakeholder interactions, dated and summarised, as evidence of ongoing engagement
- Buffer strategy: Reserve at least two weeks for unforeseen debugging issues and documentation refinement
- 阶段分配：分析 (15%)、设计 (15%)、开发与测试 (50%)、评估 (15%)、最终审查与完善 (5%) 的项目总时间
- 定期里程碑：设定每周或每两周的目标并对照审查进展；让老师参与监督
- 终端用户日志：记录所有利益相关者互动，标注日期并总结，作为持续互动的证据
- 缓冲策略：至少预留两周用于不可预见的调试问题和文档完善
11. The Role of the Teacher and Permitted Assistance | 教师的角色与允许的协助
WJEC sets clear boundaries on the level of support teachers can provide during Unit 5. While teachers are expected to offer general guidance on the process and mark scheme, they must not provide specific solutions to technical problems, write code for candidates, or substantially edit written work. Candidates should understand these boundaries to ensure they remain within the rules while still making effective use of the support available. The teacher's role is to facilitate, not to direct; the intellectual work must be the candidate's own.
WJEC 对教师在单元五期间可提供的支持水平设定了明确的界限。虽然教师应在流程和评分标准方面提供一般性指导，但他们不得为技术问题提供具体解决方案、为考生编写代码或大量编辑书面作品。考生应了解这些界限，确保在规则范围内运作的同时，有效利用可用的支持。教师的角色是促进而非指导；智力工作必须由考生自己完成。
- Permitted: General advice on project scope, clarification of mark scheme requirements, guidance on documentation structure, prompting questions to encourage reflection
- Not permitted: Debugging code, writing or rewriting sections of the report, providing specific algorithms, designing the solution, correcting technical errors
- Authentication: Teachers must confirm the work is the candidate's own; candidates should keep a development log to demonstrate authenticity
- 允许：关于项目范围的一般建议、评分标准要求的澄清、文档结构的指导、促进反思的引导性问题
- 不允许：调试代码、编写或重写报告的各个部分、提供具体算法、设计解决方案、纠正技术错误
- 真实性认证：教师必须确认作品是考生本人的；考生应保留开发日志以证明真实性
12. Final Checklist Before Submission | 提交前的最终检查清单
In the final weeks before submission, a systematic review of the entire project against the WJEC mark scheme is essential. This is not the time for major new development, but for ensuring completeness, consistency, and compliance across all sections. Candidates should methodically verify that every requirement identified in the analysis has been addressed in design, implemented in development, tested rigorously, and evaluated honestly. A fresh pair of eyes—whether a peer or the end-user—can identify gaps that the candidate has become blind to through familiarity.
在提交前的最后几周，对照 WJEC 评分标准对整个项目进行系统审查至关重要。此时不应进行重大的新开发，而应确保所有部分的完整性、一致性和合规性。考生应有条理地验证分析中确定的每项需求是否在设计中被处理、在开发中被实现、被严格测试、并被诚实评估。一双新鲜的眼睛——无论是同学还是终端用户——都能发现考生因过于熟悉而忽略的漏洞。
- Requirement traceability: Create a matrix mapping each functional requirement through design, implementation, testing, and evaluation
- Completeness check: Verify all required sections are present with substantive content; no placeholder text or 'to be completed' notes remain
- Evidence audit: Ensure every claim about functionality is supported by a screenshot, code extract, or test result
- Proofreading: Check spelling, grammar, and technical vocabulary; sloppy language undermines professional credibility
- Backup verification: Confirm that the complete project, including all code and documentation, is securely backed up in multiple locations
- 需求可追溯性：创建一个矩阵，将每项功能性需求映射到设计、实现、测试和评估
- 完整性检查：验证所有必要的部分都存在实质性内容；没有占位符文本或"待完成"的注释
- 证据审核：确保关于功能的每一个声称都有截图、代码摘录或测试结果作为支撑
- 校对：检查拼写、语法和技术词汇；草率的语言会削弱专业可信度
- 备份验证：确认完整的项目，包括所有代码和文档，已在多个位置安全备份
Published by TutorHao | Computer Science Revision Series | aleveler.com
更多咨询请联系16621398022（同微信）
或截图后用「扫一扫 → 相册」选择本图