📚 Year 12 SQA Computing: Case Study Practical Walkthrough | SQA 计算机：案例分析实战演练
Case studies are a cornerstone of the SQA Higher Computing Science course. They require you to apply theoretical knowledge to a realistic scenario, demonstrating skills in analysis, design, implementation, testing and evaluation. This walkthrough unpacks a complete case study—a Campus Event Booking System—step by step, mirroring the assignment structure you will encounter in Year 12.
案例分析是 SQA 高级计算机科学课程的核心组成部分。它要求你将理论知识应用于真实场景，展现分析、设计、实施、测试和评估的综合能力。本实战演练将逐步拆解一个完整的案例——校园活动预订系统，其结构完全对应你在 12 年级会遇到的课程作业。
1. Understanding the Case Study Brief | 理解案例任务书
Our scenario is a college that needs a digital system for students to browse and book places on extracurricular events such as workshops, sports matches and guest lectures. The system must allow event organisers to create events, specify maximum capacities, and enable students to view available slots and confirm bookings. The brief also requires persistent data storage, a search function, and an admin interface for event management.
我们的场景是一所学院需要一套数字化系统，供学生浏览和预订课外活动（如工作坊、体育比赛和客座讲座）。系统需允许活动组织者创建活动、设定最大容量，并让学生查看可用名额并确认预订。任务书还要求具备持久化数据存储、搜索功能以及用于活动管理的管理员界面。
2. The Software Development Lifecycle (SDLC) | 软件开发生命周期
The SQA Higher course emphasises an iterative approach to software development. Although you follow the classic stages—Analysis, Design, Implementation, Testing, Evaluation—you are expected to show how feedback loops influence each phase. For our booking system, we use an agile-inspired cycle, delivering a minimal viable product first, then refining based on user feedback.
SQA 高级课程强调软件开发的迭代方式。尽管你遵循经典的阶段——分析、设计、实施、测试、评估——但需要展示反馈循环如何影响每个阶段。对于我们的预订系统，我们采用受敏捷启发的周期，先交付最小可行产品，再根据用户反馈进行优化。
Key documents you must produce include a requirements specification, data flow diagrams, wireframes, a test plan, and a reflective evaluation report. The SQA markers look for consistency between the design and the final implemented solution.
你必须产出的关键文档包括需求规格说明、数据流图、线框原型、测试计划和反思性评估报告。SQA 评分员会考察设计文档与最终实现方案之间的一致性。
3. Analysis: Functional and Non-Functional Requirements | 分析阶段：功能与非功能需求
Functional requirements describe what the system should do. For the Campus Event Booking System, these include: register and authenticate users, create/update/delete events, display event lists with filters, process a booking, and prevent overbooking. Non-functional requirements cover security (hashed passwords), response time (search results under 2 seconds), and usability (clear navigation on mobile devices).
功能性需求描述系统应该做什么。对于校园活动预订系统，包括：注册并认证用户、创建/更新/删除活动、显示带筛选功能的活动列表、处理预订以及防止超额预订。非功能性需求涵盖安全性（密码哈希存储）、响应时间（搜索结果在 2 秒内）和可用性（移动设备上的清晰导航）。
We express constraints explicitly: the system must handle at least 200 concurrent users and store data in a relational database compatible with SQLite so that the assignment can be demonstrated on a school network.
我们明确表述约束条件：系统必须能承载至少 200 名并发用户，并将数据存储在兼容 SQLite 的关系型数据库中，以便在学校网络环境中演示课程作业。
4. Analysis: Scope and Stakeholder Mapping | 分析阶段：范围与利益相关者映射
Identifying end-users is critical. We have three actors: Student (can search and book events), Event Organiser (creates and manages own events), and Admin (manages all users and system settings). Each actor’s goals shape the functional requirements. For instance, a Student needs a ‘My Bookings’ dashboard, while an Organiser needs attendance reports.
识别最终用户至关重要。我们有三类角色：学生（可搜索并预订活动）、活动组织者（创建并管理自己的活动）和管理员（管理所有用户和系统设置）。每个角色的目标决定了功能性需求。例如，学生需要“我的预订”仪表板，而组织者需要出勤报告。
A context diagram places the system as a single process, showing data flows to and from external entities. We label data flows like ‘login details’, ‘event query’, ‘booking confirmation’. This high-level view keeps the analysis focused and manageable before drilling into detailed DFDs.
背景图将系统视为单个过程，展示与外部实体之间的数据流。我们标注数据流，如“登录信息”“活动查询”“预订确认”。这种高层视图使分析保持聚焦且易于管理，然后再深入到详细的数据流图。
5. Analysis: Data Flow and Process Models | 分析阶段：数据流与处理模型
We decompose the main process into Level 1 DFD: Registration, Event Management, Booking Engine, and Reporting. The Booking Engine process receives ‘event ID’ and ‘student ID’, checks capacity, and outputs ‘booking status’ to the student and updates the event store. This decomposition reveals the need for a capacity-check algorithm early on.
我们将主过程分解为一级数据流图：注册、活动管理、预订引擎和报表。预订引擎处理接收“活动ID”和“学生ID”，检查容量，输出“预订状态”给学生，并更新活动存储。这一分解在设计早期就揭示了容量检查算法的必要性。
We also create a data dictionary defining elements: Event = EventID + Title + Date + Venue + MaxCapacity + CurrentBookings. This formal notation helps with database design later.
我们还创建了数据字典来定义元素：Event = 活动ID + 标题 + 日期 + 地点 + 最大容量 + 当前预订数。这种形式化标记有助于后续的数据库设计。
6. Design: Interface Wireframes and User Experience | 设计阶段：界面线框与用户体验
Low-fidelity wireframes are drawn for every screen. The Student Home screen shows a search bar, a filter button, and a scrollable list of event cards. Each card displays title, date, and a ‘Book’ button that becomes ‘Full’ when capacity is reached. The Admin panel uses a tabbed layout for managing events, users, and site settings.
为每个屏幕绘制了低保真度线框原型。学生主页包含搜索栏、筛选按钮和可滚动的活动卡片列表。每张卡片显示标题、日期和一个“预订”按钮，容量满时按钮变为“已满”。管理员面板采用选项卡布局，用于管理活动、用户和站点设置。
Navigation flow is designed so that no page is more than three clicks away from the home screen. This reduces cognitive load and meets the usability non-functional requirement.
导航流程设计确保从主页到任何页面的点击不超过三次。这降低了认知负荷，满足可用性方面的非功能性需求。
7. Design: Data Structure and Database Schema | 设计阶段：数据结构与数据库模式
| Table | Key Fields |
|---|---|
| User | user_id (PK), username, password_hash, role |
| Event | event_id (PK), organiser_id (FK), title, date, venue, max_cap |
| Booking | booking_id (PK), event_id (FK), student_id (FK), status |
We use SQLite for portability. The Booking table acts as a junction entity, preventing duplicate bookings through a unique constraint on (event_id, student_id). A stored procedure or application-level function calculates current bookings by counting rows in Booking where status is ‘confirmed’.
我们使用 SQLite 以便于移植。预订表充当连接实体，通过对 (event_id, student_id) 设置唯一约束来防止重复预订。通过统计预订表中状态为“已确认”的行数，由存储过程或应用层函数计算当前预订数。
8. Design: Algorithm Design and Pseudocode | 设计阶段：算法设计与伪代码
The core booking algorithm must prevent race conditions when two students attempt to book the last place simultaneously. The pseudocode uses a transactional approach:
BEGIN TRANSACTION
SELECT CurrentBookings, MaxCapacity FROM Event WHERE event_id = ?
IF CurrentBookings < MaxCapacity THEN
UPDATE Event SET CurrentBookings = CurrentBookings + 1
INSERT INTO Booking VALUES (?, ?, ‘confirmed’)
COMMIT
ELSE
ROLLBACK
END IF
核心预订算法必须防止两名学生同时预订最后一个名额的竞态条件。伪代码采用事务处理方法：
开始事务
从 Event 中查询当前预订数与最大容量，条件为 event_id = ?
如果当前预订数 < 最大容量 则
更新 Event 表将当前预订数加 1
向 Booking 表插入新记录
提交事务
否则
回滚事务
结束如果
This design ensures data integrity and can be demonstrated with unit tests simulating concurrent connections.
此设计确保了数据完整性，并可通过模拟并发连接进行单元测试来验证。
9. Implementation: Coding Standards and Development | 实施阶段：编码规范与开发
We write the back-end in Python using Flask for RESTful API routes, and the front-end with HTML, CSS and vanilla JavaScript. Code follows PEP 8 style, with meaningful variable names (e.g., max_capacity). Functions are modularised: check_availability(event_id), book_event(event_id, student_id). Security practices include hashing passwords with bcrypt and using parameterised SQL queries to avoid injection.
后端使用 Python 的 Flask 框架编写 RESTful API 路由，前端使用 HTML、CSS 和原生 JavaScript。代码遵循 PEP 8 风格，变量命名有意义（如 max_capacity）。函数实现了模块化：check_availability(event_id)、book_event(event_id, student_id)。安全实践包括使用 bcrypt 对密码进行哈希，以及采用参数化 SQL 查询来防止注入。
The implementation also includes a simple search API endpoint: /api/events?q=keyword&date=YYYY-MM-DD. Results are paginated to improve performance, with each page returning 10 events.
实施过程还包含一个简单的搜索接口：/api/events?q=keyword&date=YYYY-MM-DD。结果实现了分页以提高性能，每页返回 10 个活动。
10. Testing: Strategies and Test Cases | 测试阶段：策略与测试用例
A comprehensive test plan is essential for the SQA assignment. We use black-box testing for user journeys: ‘Student successfully books an available event’, ‘Booking fails when event is full’. White-box testing covers the booking algorithm’s boundaries, for example testing with exactly max_capacity bookings and one more.
全面的测试计划对 SQA 课程作业至关重要。我们使用黑盒测试验证用户路径：“学生成功预订有名额的活动”“活动满额时预订失败”。白盒测试覆盖预订算法的边界情况，例如刚好完成最大容量数量的预订，再尝试多一次预订。
| Test ID | Description | Expected Outcome |
|---|---|---|
| TC01 | Register with valid credentials | Account created, redirected to login |
| TC02 | Book last available spot concurrently (2 users) | Only one booking confirmed, other gets ‘full’ message |
Usability testing involves three real students performing tasks and reporting any confusion. The feedback leads to labels being added to icon buttons, improving accessibility.
可用性测试邀请三名真实学生执行任务并报告困惑之处。根据反馈在图标按钮旁增加了文字标签，提高了无障碍性。
11. Evaluation and Maintenance | 评估与维护
Evaluation judges the solution against the original analysis. Our system meets all functional requirements: booking, capacity tracking, admin interface. The non-functional requirement of sub-2-second response is measured using Python’s time library; average search time was 0.4 seconds locally. We identify two limitations: the absence of email notifications and the lack of a calendar export feature.
评估依据最初的分析来评判解决方案。我们的系统满足了所有功能性需求：预订、容量追踪、管理员界面。非功能性需求中的 2 秒内响应通过 Python 的 time 库进行测量；本地平均搜索时间为 0.4 秒。我们识别出两项局限：缺少邮件通知功能，以及缺少日历导出功能。
Maintenance plans are discussed: future iterations could add a recommendation engine based on past bookings and integrate the college’s single sign-on. The evaluation commentary explicitly links these to the iterative nature of the SDLC.
讨论了维护计划：未来的迭代可以添加基于历史预订的推荐引擎，并集成学院的单点登录系统。评估评论明确将这些计划与软件开发生命周期的迭代本质联系起来。
12. Legal, Ethical and Environmental Implications | 法律、伦理与环境影响
Under the UK Data Protection Act and GDPR, the system must store personal data securely, obtain consent for data processing, and allow users to request data deletion. Our design includes a ‘Delete My Account’ feature and a privacy policy page. Ethically, the system must not discriminate; for example, the booking queue must be first-come-first-served, insensitive to user demographics.
根据英国《数据保护法》和 GDPR，系统必须安全存储个人数据，获取数据处理同意书，并允许用户请求删除数据。我们的设计包含“删除我的账户”功能和隐私政策页面。在伦理层面，系统必须公平无歧视；例如，预订队列采用先到先得规则，不受用户背景的影响。
Environmental concerns are addressed by noting that the booking system reduces paper-based forms and administrative travel. The evaluation could discuss how server energy consumption can be minimised through efficient code and hosting choice, an aspect increasingly valued by SQA.
环境影响方面，预订系统减少了纸质表单和行政出行。评估报告可以探讨如何通过高效代码和主机选择将服务器能耗降至最低，这一点日益受到 SQA 的重视。
Published by TutorHao | Computing Revision Series | aleveler.com
更多咨询请联系16621398022（同微信）
屏轩国际教育cambridge primary/secondary checkpoint, cat4, ukiset,ukcat,igcse,alevel,PAT,STEP,MAT, ibdp,ap,ssat,sat,sat2课程辅导，国外大学本科硕士研究生博士课程论文辅导Cancel reply