📚 Case Study Practical Exercises | 案例分析实战演练
This article presents a comprehensive case study walkthrough designed for Year 13 OCR A Level Computer Science students. It simulates the practical application of systems analysis, design, data modelling, algorithm development, and testing within a realistic project scenario. Working through this exercise will strengthen your ability to tackle exam-style component 2 and 3 questions that require you to analyse, design, and evaluate a computerised solution from scratch.
本文为 OCR A Level 计算机科学 Year 13 学生提供一份完整的案例分析实战演练。我们模拟了一个真实项目场景，涵盖系统分析、设计、数据建模、算法开发和测试等核心环节。通过逐步完成本练习，你将更从容地应对试卷 2 和 3 中需要从零分析、设计并评估计算机解决方案的考题。
1. Introducing the Scenario – MedTrack Clinic | 场景介绍：MedTrack 诊所
The case study revolves around a small private medical clinic called MedTrack. The clinic currently uses paper records for patient registrations, appointment bookings, and prescriptions. The management wants to replace the entire manual system with a computerised information system that can handle patient records, GP appointments, prescription management, and basic billing. Your task is to work through the full systems development life cycle for this project, producing key deliverables along the way.
案例围绕一家名为 MedTrack 的小型私立诊所展开。该诊所目前使用纸质记录管理患者注册、预约挂号和处方。管理层希望用一套计算机化信息系统取代所有手动流程，要求系统能够处理患者记录、全科医生预约、处方管理以及基本计费。你的任务是走完整个系统开发生命周期，并逐步产出关键交付物。
2. Feasibility and Initial Fact-Finding | 可行性研究与初步调研
Before committing to full development, a brief feasibility study is necessary. Economic feasibility: The clinic expects to recover the £25 000 development cost within two years through reduced administrative overhead and fewer missed appointments. Technical feasibility: The clinic already has a local server and ten workstations running Windows, making a web-based client-server solution appropriate. Operational feasibility: Staff are receptive to the change, provided the system mimics their current workflow and includes adequate training.
在全面投入开发前，必须进行简要的可行性研究。经济可行性：诊所预计通过减少行政开销和避免预约失约，可在两年内收回 £25 000 的开发成本。技术可行性：诊所现有一台本地服务器和十台运行 Windows 的工作站，因此基于 Web 的客户-服务器方案很合适。操作可行性：员工愿意接受变革，但前提是系统能够模拟他们现有的工作流程并提供充分的培训。
Fact-finding methods include interviews with the clinic manager, two GPs, and a receptionist, observation of the current paper-based processes, and a questionnaire sent to 50 patients to gauge interest in online appointment booking. The key findings show that 78% of patients would prefer to book appointments online, and the receptionist spends 3 hours daily manually searching for patient records and managing cancellations.
调研方法包括与诊所经理、两名全科医生和一名接待员进行访谈，观察当前纸质流程，以及向 50 名患者发放问卷以评估在线预约的兴趣。关键发现显示，78% 的患者更希望在线预约，而接待员每天花费三小时手动查找患者记录和处理取消预约。
3. Requirements Specification – Functional and Non-Functional | 需求规格说明：功能性需求与非功能性需求
Functional requirements include: the system must store patient demographic details and medical history; allow receptionists to create, reschedule, and cancel appointments; enable GPs to record consultation notes and issue electronic prescriptions; generate invoices automatically based on appointment type; and provide a patient portal for self-service booking. Non-functional requirements: the system must support up to 10 concurrent users with a page response time under 3 seconds; patient data must be encrypted at rest and in transit; the system should be available 99.5% during clinic operating hours; and the user interface must comply with WCAG 2.1 AA accessibility standards.
功能性需求包括：系统必须存储患者人口统计信息和病史；允许接待员创建、修改和取消预约；使全科医生能够记录会诊笔记并开具电子处方；根据预约类型自动生成账单；并提供患者自助预约门户。非功能性需求：系统必须支持最多 10 名并发用户，页面响应时间小于 3 秒；患者数据在存储和传输中均须加密；在诊所运营时段内系统可用性须达到 99.5%；用户界面须符合 WCAG 2.1 AA 无障碍标准。
4. Context Diagram and Data Flow Modelling | 背景图与数据流建模
A context diagram places the MedTrack system as a single process interacting with four external entities: Patient, Receptionist, GP, and Accountant. Data flows entering the system include RegistrationRequest, AppointmentRequest, PrescriptionOrder, and PaymentDetails. Outgoing flows include AppointmentConfirmation, PrescriptionPDF, Invoice, and MedicalReport. Labelling each flow with a clear name ensures all stakeholders understand the boundary of the system.
背景图将 MedTrack 系统视为单一过程，与四个外部实体交互：患者、接待员、全科医生和会计。进入系统的数据流包括注册请求、预约请求、处方医嘱和付款详情。离开系统的数据流包括预约确认、处方 PDF、账单和医疗报告。为每条数据流标注清晰名称可确保所有利益相关方理解系统的边界。
At Level 0, the system is decomposed into five major processes: 1.0 Manage Patient Registration, 2.0 Schedule Appointment, 3.0 Conduct Consultation, 4.0 Issue Prescription, and 5.0 Generate Invoice. Data stores such as D1 PatientFile, D2 AppointmentBook, and D3 PrescriptionLog hold persistent data. The data flow diagram (DFD) reveals that process 2.0 requires access to both PatientFile and AppointmentBook, highlighting a need for robust referential integrity between patient records and appointments.
在 0 级图中，系统被分解为五个主要过程：1.0 管理患者注册、2.0 安排预约、3.0 进行会诊、4.0 开具处方和 5.0 生成账单。数据存储 D1 患者档案、D2 预约簿和 D3 处方日志保存持久数据。数据流图显示过程 2.0 需要同时访问患者档案和预约簿，这凸显了患者记录与预约之间需要强大的参照完整性。
5. Entity Relationship Diagram and Database Design | 实体关系图与数据库设计
After analysing the DFD, we identify four core entities: Patient (attributes: PatientID, FullName, DOB, NHSNumber, Address, Phone), GP (GPID, FullName, Specialisation), Appointment (AppointmentID, DateTime, Status, Type), and Prescription (PrescriptionID, DrugName, Dosage, DateIssued). A Patient can have many Appointments (1:M), a GP conducts many Appointments (1:M), and a Prescription is linked to one Appointment (1:1), though in practice one consultation may result in multiple prescriptions, so we model it as 1:M from Appointment to Prescription.
分析数据流图后，我们确定了四个核心实体：Patient（属性：患者ID、姓名、出生日期、NHS编号、地址、电话）、GP（全科医生ID、姓名、专长）、Appointment（预约ID、日期时间、状态、类型）和 Prescription（处方ID、药品名、剂量、开具日期）。一个患者可以有多个预约（1:M），一个全科医生进行多次预约（1:M），而处方与预约相关联。虽然最初认为是一对一，但实际一次会诊可能开出多张处方，因此我们将 Appointment 到 Prescription 的关系建模为 1:M。
The logical schema is normalised to Third Normal Form (3NF). For instance, the Prescription table includes a foreign key AppointmentID referencing Appointment. A composite table AppointmentPatientGP is avoided by placing foreign keys PatientID and GPID directly in the Appointment table, ensuring no partial dependencies. The design uses integer surrogate keys for all primary keys, and enforces unique constraints on NHSNumber and composite uniqueness on (DrugName, Dosage, AppointmentID) to prevent duplicate prescriptions within the same consultation.
逻辑模式被规范化到第三范式（3NF）。例如，Prescription 表包含外键 AppointmentID 引用 Appointment。通过在 Appointment 表中直接放置外键 PatientID 和 GPID，避免了创建复合表，从而确保没有部分依赖。设计对所有主键使用整数代理键，并对 NHSNumber 施加唯一约束，同时为 (DrugName, Dosage, AppointmentID) 设置复合唯一约束，以防止同一会诊内出现重复处方。
6. User Interface Prototype – High-Fidelity Mockup | 用户界面原型：高保真模型
The receptionist’s main dashboard is prototyped using a wireframe that evolves into a high-fidelity HTML/CSS mockup. The screen displays a searchable patient list on the left pane, a central weekly calendar with colour-coded appointment slots (green for available, red for booked, yellow for pending), and a quick-action panel on the right for registering a new patient or sending an appointment reminder SMS. A minimalist navigation bar sits at the top with tabs: Patients, Appointments, Billing, Reports.
接待员的主仪表板先用线框图原型，再发展为高保真 HTML/CSS 模型。屏幕左侧显示可搜索的患者列表，中间是一个带颜色编码的周视图日历（绿色表示可预约、红色表示已预订、黄色表示待确认），右侧则是快速操作面板，用于注册新患者或发送预约提醒短信。顶部的极简导航栏包含选项卡：患者、预约、账单、报表。
To validate the UI, we conduct a cognitive walkthrough with the receptionist. She successfully completes tasks such as finding a patient by surname, booking a new appointment, and cancelling a double-booked slot. Feedback leads to the addition of a confirmation dialog before deletion and a visual indicator when the GP’s calendar exceeds five appointments per day, which triggers an overload warning.
为了验证用户界面，我们与接待员一起进行了认知走查。她成功完成了按姓氏查找患者、预订新预约以及取消重复预约等任务。反馈促使我们增加了删除前的确认对话框，并在全科医生每天预约超过五个时显示视觉提示，触发超负荷警告。
7. Algorithm Design – Appointment Conflict Checker | 算法设计：预约冲突检测器
A critical piece of business logic is ensuring that no two appointments overlap for the same GP. We design a binary search–based algorithm operating on a sorted array of existing appointments for a given GP and date. The function accepts a proposed start time tstart and end time tend. It first executes a binary search to find the index where tstart would be inserted while maintaining sort order. Then it checks the immediate neighbours: if the previous appointment’s end time > tstart or the next appointment’s start time < tend, a conflict exists and the function returns false; otherwise true.
一条关键业务逻辑是确保同一全科医生的任何两个预约时间不会重叠。我们设计了一个基于二分查找的算法，该算法作用于某位全科医生在某天已有预约的排序数组。函数接受提议的开始时间 tstart 和结束时间 tend。它首先执行二分查找，找到按序插入 tstart 的索引位置。然后检查直接邻居：如果上一个预约的结束时间大于 tstart，或下一个预约的开始时间小于 tend，则存在冲突，函数返回 false；否则返回 true。
The time complexity of this approach is O(log n) for the search plus O(1) for checking neighbours, making it highly efficient even when the GP has hundreds of daily slots in a multi-year historical dataset. We implement it in pseudocode first, then translate to Python using the bisect module for production code. We also write unit tests with boundary cases: exactly adjacent appointments (no conflict), back-to-back bookings, and same start time as an existing appointment (conflict).
该方法的时间复杂度为 O(log n) 的查找加上 O(1) 的邻居检查，因此即使全科医生在多年度历史数据中有数百个当日时段，算法仍能保持高效。我们先用伪代码实现，然后在生产代码中使用 Python 的 bisect 模块进行翻译。我们还编写了包含边界情况的单元测试：恰好相邻的预约（无冲突）、背靠背预订以及与现有预约相同的开始时间（冲突）。
8. Security and Data Protection by Design | 安全与数据保护设计
MedTrack handles sensitive personal data classified as special category under UK GDPR. Our security measures start at the database layer: all patient-identifiable columns are encrypted using AES-256, with encryption keys stored in a hardware security module (HSM). Access control follows role-based principles: the receptionist role has SELECT and INSERT privileges on Appointment and Patient tables but cannot view full medical history notes; GP role has full access to their own patients’ records but cannot modify billing data; accountant role can only access anonymised appointment counts and invoice tables.
MedTrack 处理的是英国 GDPR 下归类为特殊类别的敏感个人数据。我们的安全措施从数据库层开始：所有可识别患者身份的列均使用 AES-256 加密，加密密钥存储在硬件安全模块（HSM）中。访问控制遵循基于角色的原则：接待员角色对 Appointment 和 Patient 表具有 SELECT 和 INSERT 权限，但无法查看完整的病历笔记；全科医生角色可完全访问其自己的患者记录，但无法修改计费数据；会计角色只能访问匿名化的预约统计和发票表。
Audit trails capture every access to patient records, storing the timestamp, user ID, record ID, and action type (VIEW, UPDATE, DELETE). The log is write-once and retained for six years. Additionally, the patient portal enforces multi-factor authentication using a one-time passcode sent via SMS, and all communication between client and server is secured with TLS 1.3. These design choices are not just technical; they demonstrate compliance with the Data Protection Act 2018 principles of data minimisation, integrity, and confidentiality.
审计追踪记录了每次对患者记录的访问，存储时间戳、用户 ID、记录 ID 和操作类型（查看、更新、删除）。审计日志采用一次写入、保留六年的策略。此外，患者门户强制使用通过短信发送一次性验证码的多因素认证，客户端与服务器之间的所有通信均使用 TLS 1.3 进行安全保护。这些设计选择不仅仅是技术性的；它们证明了我们对《2018 年数据保护法》中数据最小化、完整性和保密性原则的遵守。
9. Testing Strategy – From Unit to Acceptance | 测试策略：从单元测试到验收测试
A robust V-model testing approach is adopted. At the unit level, developers test the conflict-checker algorithm with JUnit-style frameworks, covering equivalence partitions for valid and invalid time ranges, and edge cases such as appointments spanning midnight. Integration testing verifies that the appointment booking module correctly updates both the Appointment table and the Prescription table in a single transaction; a rollback is triggered if the prescription insertion fails. System testing evaluates the whole system against functional requirements, including simulated load with up to 15 concurrent virtual users to ensure response times remain under 3 seconds.
我们采用稳健的 V 模型测试方法。在单元级别，开发人员使用类似 JUnit 的框架测试冲突检测算法，覆盖有效和无效时间范围的等价划分，以及跨越午夜的边界情况。集成测试验证预约预订模块在单次事务中正确更新 Appointment 表和 Prescription 表；如果处方插入失败，则触发回滚。系统测试对照功能性需求评估整个系统，包括使用最多 15 个并发虚拟用户进行模拟负载，确保响应时间保持在 3 秒以下。
User acceptance testing (UAT) involves real staff processing a full day’s typical transactions in a staging environment. The success criterion is that 95% of tasks are completed without assistance, and the average appointment booking time drops below 1 minute (compared to 4 minutes manually). UAT results reveal a minor issue: when a patient cancels an appointment within 2 hours, the system still attempts to send an SMS reminder. This is corrected before go-live.
用户验收测试（UAT）让真实员工在预生产环境中处理全天典型事务。成功标准是 95% 的任务在无协助下完成，且平均预约预订时间降至 1 分钟以下（手动操作时为 4 分钟）。UAT 结果揭示了一个小问题：当患者在预约前 2 小时内取消时，系统仍尝试发送短信提醒。该问题在上线前得到纠正。
10. Evaluation and Maintenance Planning | 评估与维护规划
Post-implementation evaluation compares actual metrics against the feasibility projections. Six months after deployment, the clinic reports a 35% reduction in administrative staff overtime, and patient no-shows have dropped from 12% to 4%. The system has maintained 99.8% uptime. However, the patient portal adoption rate among patients over 65 is only 20%, indicating a need for additional outreach or a simplified kiosk interface in the waiting area. This feedback loop triggers the first major change request: an on-site self-check-in terminal.
实施后评估将实际指标与可行性预测进行比较。部署六个月后，诊所报告行政人员加班时间减少了 35%，患者失约率从 12% 降至 4%。系统正常运行时间保持在 99.8%。然而，65 岁以上患者对患者门户的采用率仅为 20%，这表明需要在候诊区增加外展服务或简化自助终端界面。此反馈循环触发了第一个重大变更请求：现场自助签到终端。
Maintenance planning categorises future work into corrective (fixing a rare deadlock bug when two receptionists simultaneously modify the same appointment), adaptive (upgrading the TLS library when a vulnerability is disclosed), and perfective (adding a machine-learning module to predict no-shows based on historical data). A service-level agreement with the development team guarantees 4-hour critical bug response, ensuring the clinic can continue to rely on the system for its daily operations.
维护规划将未来工作分为纠正性（修复两名接待员同时修改同一预约时出现的罕见死锁错误）、适应性（在披露漏洞时升级 TLS 库）和完善性（增加基于历史数据预测失约的机器学习模块）。与开发团队签订的服务级别协议保证关键错误 4 小时响应，确保诊所能够继续依赖该系统进行日常运营。
11. OCR Exam-Style Discussion Questions | OCR 考试风格讨论题
To consolidate your understanding, attempt these questions: 1. Explain why the clinic chose a web-based architecture over a native desktop application. 2. Describe two measures to prevent SQL injection in the patient search feature. 3. Evaluate the ethical implications of using patient data to train a no-show prediction model without explicit consent. 4. Draw a Level 1 DFD for process 2.0 Schedule Appointment, showing its sub-processes and data stores. Model answers should reference the specific technologies and design decisions described in this case study.
为巩固理解，请尝试回答以下问题：1. 解释诊所为么选择基于 Web 的架构而非原生桌面应用。2. 描述防止患者搜索功能中 SQL 注入的两项措施。3. 评估在未经明确同意的情况下使用患者数据训练失约预测模型的伦理影响。4. 为过程 2.0 安排预约绘制 1 级数据流图，展示其子过程和数据存储。标准答案应引用本案例研究中描述的具体技术和设计决策。
12. Conclusion and Key Takeaways | 总结与要点提炼
This case study has walked you through the entire systems development life cycle for a realistic clinic management system, from initial fact-finding to post-implementation evaluation. The interdisciplinary nature of the exercise – blending data modelling, algorithm efficiency, cybersecurity, usability, and regulatory compliance – reflects the integrated approach expected in OCR A Level Computer Science examinations. Always remember to justify your design choices with reference to the scenario’s constraints, and to consider the human and ethical dimensions alongside technical solutions.
本案例研究带你走完了真实诊所管理系统从初步调研到实施后评估的整个系统开发生命周期。练习的跨学科特性——融合了数据建模、算法效率、网络安全、可用性和法规遵从——反映了 OCR A Level 计算机科学考试所期望的综合方法。请始终记住，要结合场景约束来证明你的设计选择，并在技术方案之外考虑人文和伦理维度。
Published by TutorHao | Computer Science Revision Series | aleveler.com
更多咨询请联系16621398022（同微信）
屏轩国际教育cambridge primary/secondary checkpoint, cat4, ukiset,ukcat,igcse,alevel,PAT,STEP,MAT, ibdp,ap,ssat,sat,sat2课程辅导，国外大学本科硕士研究生博士课程论文辅导