📚 Pre-U WJEC Computer Science: Practical Lab Assessment Essentials | 预科WJEC计算机科学：实验/实践考核要点
Mastering the practical component of the WJEC Computer Science qualification requires more than just writing code - it demands systematic analysis, rigorous design, iterative development and comprehensive evaluation. This article breaks down the essential assessment criteria and proven strategies for the programming project or Non-Exam Assessment (NEA), equipping you to achieve top marks through a structured, evidence-rich approach.
要掌握WJEC计算机科学资格认证的实践部分，仅仅会写代码是不够的——它需要系统化的分析、严谨的设计、迭代式的开发以及全面的评估。本文分解了编程项目或非考试评估（NEA）的核心考核标准与行之有效的策略，帮助你通过结构化、证据丰富的方法获得高分。
1. Understanding the Assessment Objectives | 理解评估目标
WJEC's practical lab assessment is primarily aligned with AO2 (Application of knowledge) and AO3 (Design, development and evaluation). AO2 demands that you apply computational thinking to decompose real-world problems, while AO3 expects you to design, implement, test and reflect upon a complete programmed solution. Examiners look for clear links between theoretical concepts and hands-on evidence.
WJEC的实践考核主要对应AO2（知识应用）和AO3（设计、开发与评估）。AO2要求你运用计算思维分解现实问题，而AO3则期望你设计、实现、测试并反思一个完整的编程解决方案。考官寻找的是理论概念与实践证据之间的清晰关联。
- AO2: Apply knowledge to break down complex scenarios into manageable components. | AO2：运用知识将复杂场景分解为可管理的组件。
- AO3: Demonstrate a systematic, iterative development process backed by a well-maintained folder of evidence. | AO3：通过维护良好的证据文件夹，展示系统化、迭代式的开发过程。
2. Problem Identification and Stakeholder Engagement | 问题识别与利益相关方参与
Select a genuine problem where a software solution can add tangible value. Identify the end-user(s) and their specific needs through interviews, observation or questionnaires. Real stakeholder interaction strengthens the 'Analysis' section and provides authentic criteria against which success can later be measured.
选择一个软件解决方案能够带来切实价值的真实问题。通过访谈、观察或问卷调查识别最终用户及其具体需求。真实的利益相关方互动能强化“分析”部分，并提供日后衡量成功与否的真实标准。
- Document user profiles, current workflows and pain points. | 记录用户画像、当前工作流程和痛点。
- Set SMART (Specific, Measurable, Achievable, Relevant, Time-bound) success criteria that the final product must meet. | 设定最终产品必须满足的SMART（具体的、可衡量的、可实现的、相关的、有时限的）成功标准。
3. Detailed Requirements Analysis | 详细需求分析
Translate user stories into a structured list of functional and non-functional requirements. Use tools like context diagrams, data flow diagrams (DFD) or use case diagrams to visualise system boundaries and interactions. This stage must be driven by computational thinking - abstraction, decomposition and pattern recognition.
将用户故事转化为结构化的功能与非功能需求列表。使用环境图、数据流图（DFD）或用例图等工具来可视化系统边界与交互。此阶段必须由计算思维驱动——抽象、分解和模式识别。
- Functional requirements: what the system must do (e.g., 'The system shall allow a librarian to search for books by title or author'). | 功能需求：系统必须做什么（例如，“系统应允许图书管理员按书名或作者搜索图书”）。
- Non-functional requirements: constraints such as performance, security, usability and platform. | 非功能需求：性能、安全性、可用性和平台等约束条件。
4. Designing a Robust Solution | 设计稳健的解决方案
Present a multi-layered design including algorithms (flowcharts or pseudocode), data structures, user interface mockups and a modular architecture. Explain the rationale behind key design decisions - for instance, why you chose a hash table over an array for fast lookups, or why a normalised relational database suits the problem. A trace table can validate algorithm logic early.
展示包含算法（流程图或伪代码）、数据结构、用户界面模型和模块化架构的多层次设计。解释关键设计决策背后的理由——例如，为什么为了提高查找速度选择了哈希表而非数组，或者为什么规范化关系型数据库适合该问题。跟踪表可在早期验证算法逻辑。
Complexity: O(log n) for binary search vs O(n) for linear search
复杂度：二分查找 O(log n) 对比线性查找 O(n)
5. Iterative Development and Version Control | 迭代开发与版本控制
Do not attempt to build the entire solution in one sprint. Break development into manageable phases, each producing a testable increment. Maintain a development log that records daily progress, challenges faced and how they were resolved. Use version control (e.g., Git) even for a solo project; the commit history serves as powerful evidence of iterative refinement.
不要试图在一个冲刺中构建整个解决方案。将开发分解为可管理的阶段，每个阶段产出一个可测试的增量。维护开发日志，记录每日进展、面临的挑战及其解决方式。即使是独立项目，也要使用版本控制（如Git）；提交历史是迭代优化强有力的证据。
- Phase 1: Core data handling and file I/O. | 第一阶段：核心数据处理与文件输入/输出。
- Phase 2: Search and filter functionality. | 第二阶段：搜索与筛选功能。
- Phase 3: User interface and reporting. | 第三阶段：用户界面与报告。
6. Comprehensive Testing Strategies | 全面的测试策略
Testing must go beyond 'it works on my machine'. Design a test plan with clear test IDs, input data, expected outcomes, actual outcomes and pass/fail status. Include normal, boundary and erroneous test cases. Use automated unit tests where feasible, and reference the original success criteria to prove that all requirements have been met.
测试不能止步于“在我的机器上能运行”。设计包含清晰测试编号、输入数据、预期结果、实际结果和通过/失败状态的测试计划。纳入正常、边界和错误测试用例。在可行的情况下使用自动化单元测试，并引用原始成功标准来证明所有需求均已满足。
| Test ID | 测试编号 | Type | 类型 | Input | 输入 | Expected | 预期 | Result | 结果 |
|---|---|---|---|---|
| T001 | Normal | Search 'Orwell' | List of matching books | Pass |
| T002 | Boundary | Empty search field | Prompt 'Enter a keyword' | Pass |
| T003 | Erroneous | SQL injection: ' OR '1'='1 | Sanitised; no unauthorised access | Pass |
7. Critical Evaluation and Reflection | 批判性评估与反思
The evaluation must be a honest, objective analysis of what went well and what could be improved. Compare the final product against the original success criteria, discuss limitations (e.g., 'the current system only supports single-user access'), and suggest realistic future enhancements. Reflection on your own technical and organisational skills shows deep engagement with the project lifecycle.
评估必须是对哪些方面做得好、哪些方面可以改进的诚实、客观的分析。将最终产品与最初的成功标准进行比较，讨论局限性（例如，“当前系统仅支持单用户访问”），并提出切实可行的未来改进建议。对自身技术与组织技能的反思，展现了对项目生命周期的深入参与。
- Strengths: 'The barcode scanning module increased data entry speed by 40% in user trials.' | 优势：“条形码扫描模块在用户试用中将数据录入速度提高了40%。”
- Limitations: 'Due to time constraints, the reporting module exports only PDF, not Excel.' | 局限性：“由于时间限制，报告模块仅可导出PDF，不支持Excel。”
8. Evidence Presentation and Write-up | 证据呈现与文档撰写
The project folder is your exam script. Organise it logically with a contents page, numbered sections and cross-referencing. Use screenshots with annotations to show code snippets, error messages and UI evolution. Maintain a consistent referencing style for any external resources, and ensure the final write-up explains not just what you did but why you did it - linking back to computational thinking principles.
项目文件夹就是你的答卷。用目录页、编号章节和交叉引用进行合理组织。使用带标注的屏幕截图展示代码片段、错误信息和用户界面的演进。对外部资源保持一致的引用格式，并确保最终文档不仅说明你做了什么，而且解释为什么这么做——与计算思维原则联系起来。
Evidence = Code listings + Annotated screenshots + Test logs + Meeting notes
证据 = 代码清单 + 带注释的截屏 + 测试日志 + 会议记录
9. Time Management and Milestone Planning | 时间管理与里程碑规划
Allocate dedicated time each week to the NEA from the very start of the course. Create a Gantt chart or timeline with clear deadlines for analysis, design, prototype, testing and final submission. Factor in buffer time for unforeseen technical difficulties - a corrupted database file or library incompatibility can easily derail a schedule without contingency planning.
从课程一开始就每周为NEA分配专用时间。创建甘特图或时间线，为分析、设计、原型、测试和最终提交设定明确的截止日期。为不可预见的技术困难预留缓冲时间——数据库文件损坏或库不兼容等意外，若没有应急计划，很容易打乱时间表。
- Week 1-3: Stakeholder interviews, problem definition, success criteria. | 第1-3周：利益相关方访谈、问题定义、成功标准。
- Week 4-6: Full design documentation and algorithm walkthroughs. | 第4-6周：完整的设计文档和算法走查。
- Week 7-12: Phased development and internal testing. | 第7-12周：分阶段开发与内部测试。
- Week 13-15: User acceptance testing, evaluation write-up, final polish. | 第13-15周：用户验收测试、评估撰写、最终润色。
10. Common Pitfalls and How to Avoid Them | 常见陷阱与规避之道
Many candidates lose marks not because of poor programming, but due to weak documentation or superficial evaluation. Avoid over-ambitious scope that leads to incomplete functionality; it is better to fully implement a smaller, well-defined system. Never fabricate stakeholder feedback - examiners can easily detect generic or scripted interactions. Finally, backup your work obsessively across multiple locations, including cloud storage.
许多考生失分并非因为编程能力差，而是因为文档薄弱或评估肤浅。避免过于雄心勃勃的范围导致功能不完整；宁可完整实现一个小而精的系统。切勿捏造利益相关方反馈——考官很容易识别出泛泛或照本宣科的互动。最后，务必在多个位置（包括云端）疯狂备份你的工作成果。
| Pitfall | 陷阱 | Impact | 影响 | Prevention | 预防措施 |
|---|---|---|
| Missing success criteria | Weak evaluation, no benchmark | Write SMART criteria in analysis phase |
| No version history | Cannot prove iterative development | Use Git from Day 1, commit frequently |
| All tests passed on first run | Unrealistic; reduces credibility | Include genuine bug discovery and retests |
11. Linking Theory to Practice | 将理论与实践相结合
Examiners reward candidates who explicitly connect their practical work to the theoretical knowledge from the written paper. For example, discuss how a relational database schema reduces data redundancy (normalisation), or how the choice of a quick sort algorithm relates to time complexity and memory constraints. Mentioning relevant models such as the System Development Life Cycle (SDLC) or Agile methodology adds academic depth.
考官会奖励那些将实践工作与书面考试中的理论知识明确联系起来的考生。例如，讨论关系型数据库模式如何减少数据冗余（规范化），或者快速排序算法的选择如何与时间复杂度和内存限制相关。提及系统开发生命周期（SDLC）或敏捷方法等相关模型，能增加学术深度。
- Computational thinking: abstraction in data models, decomposition in module design. | 计算思维：数据模型中的抽象，模块设计中的分解。
- Legal and ethical: reference to GDPR when handling personal data in the project. | 法律与伦理：在项目中处理个人数据时引用GDPR。
12. Final Submission Checklist | 最终提交检查清单
Before submitting, verify that every page is numbered, all hyperlinks work, and the compiled document is in the required format (usually PDF). Ask a peer to review your evidence folder for clarity - if they cannot follow the project narrative, an examiner might struggle too. Re-read the WJEC mark scheme against your work to ensure no assessment criterion has been overlooked.
提交前，请核实每一页都有编号，所有超链接正常，汇编文档符合要求的格式（通常为PDF）。请同伴审查你的证据文件夹以确认清晰度——如果他们无法理解项目叙事，考官可能也会感到困惑。对照你的作品重新阅读WJEC评分方案，确保没有遗漏任何评估标准。
- Check: analysis, design, development log, test plan and evaluation are all present. | 检查：分析、设计、开发日志、测试计划和评估全部齐全。
- Check: any third-party assets are properly credited and permitted. | 检查：所有第三方资源均已适当注明来源且获许可。
Published by TutorHao | Computer Science Revision Series | aleveler.com
更多咨询请联系16621398022（同微信）
或截图后用「扫一扫 → 相册」选择本图