📚 A-Level Computer Science: System Evaluation Criteria and Methods | A-Level 计算机：系统评估标准与方法
System evaluation is a critical stage in the systems life cycle. It determines whether a newly developed or modified computer system meets its original objectives, performs efficiently, and remains viable for future use.
系统评估是系统生命周期中的关键阶段。它用于判断新开发或修改后的计算机系统是否达成最初目标、运行高效，并在未来仍然具有可行性。
In the CIE A-Level Computer Science syllabus, learners must understand both the criteria used to judge a system and the methods by which these criteria are measured. This article explores these ideas in depth, with reference to real-world applications and examination-style explanations.
在 CIE A-Level 计算机科学大纲中，考生必须理解判断系统的标准以及衡量这些标准的各种方法。本文将深入探讨这些概念，并联系实际应用和考试风格的讲解。
1. The Purpose of System Evaluation | 系统评估的目的
Evaluation is not a single event that happens at the end of development. It should occur throughout the systems life cycle, particularly during testing, after implementation, and during periodic reviews.
评估并不是开发结束时的单一事件。它应贯穿系统生命周期始终，尤其在测试期间、实施完成后以及定期审查时进行。
The main purposes of evaluation are to check whether the system satisfies user requirements, to identify any weaknesses or failures, to compare the system against alternative solutions, and to inform decisions about maintenance or replacement.
评估的主要目的是检查系统是否满足用户需求、识别任何弱点或故障、将系统与替代方案进行比较，并为维护或更换决策提供依据。
For example, a new online banking system must be evaluated not only for functional correctness, but also for security, response time under high load, and ease of use for elderly customers.
例如，新的网上银行系统不仅需要评估功能正确性，还要评估安全性、高负载下的响应时间以及老年客户的易用性。
2. Evaluation Criteria: Efficiency | 评估标准：效率
Efficiency measures how well a system uses resources such as CPU time, memory, disk space, and network bandwidth. A system may be functionally correct but inefficient if it consumes excessive resources.
效率衡量系统对 CPU 时间、内存、磁盘空间和网络带宽等资源的使用情况。一个系统可能在功能上正确，但如果消耗过多资源，那它仍是低效的。
Throughput is a key efficiency measure. It represents the amount of work completed in a fixed time period, for example the number of transactions processed per second. In a database system, a higher transaction throughput often indicates better efficiency.
吞吐量是关键的效率指标。它表示在固定时间内完成的工作量，例如每秒处理的事务数。在数据库系统中，更高的事务吞吐量通常意味着更高的效率。
Formula for throughput can be expressed conceptually as:
吞吐量的概念公式可表示为：
Throughput = Total work completed ÷ Time taken
吞吐量 = 完成的总工作量 ÷ 所用时间
Another measure is CPU utilisation, the percentage of time the processor is actively executing instructions. Very high CPU utilisation may indicate a bottleneck, while very low utilisation suggests underuse of the hardware.
另一个指标是 CPU 利用率，即处理器积极执行指令的时间百分比。极高的 CPU 利用率可能表示存在瓶颈，而极低的利用率则表明硬件未被充分利用。
3. Evaluation Criteria: Response Time and Latency | 评估标准：响应时间与延迟
Response time is the interval between a user submitting a request and the system presenting the result. For interactive systems such as air traffic control or video conferencing, low response time is essential.
响应时间是从用户提交请求到系统呈现结果之间的间隔。对于空中交通管制或视频会议等交互式系统，低响应时间至关重要。
Latency refers to the delay before data transfer or processing begins. In network systems, latency includes propagation delay, transmission delay, and processing delay. A system with high latency may feel slow even if its throughput is high.
延迟指数据传输或处理开始之前的等待时间。在网络系统中，延迟包括传播延迟、传输延迟和处理延迟。一个高延迟的系统即使吞吐量很高，也可能会让人感到缓慢。
In real-time systems, such as a car's anti-lock braking system, response time must be predictable and bounded. Missing a deadline could lead to catastrophic failure.
在实时系统中，例如汽车的防抱死制动系统，响应时间必须是可预测且有界的。错过最后期限可能导致灾难性故障。
Response time = time from user request to visible output.
响应时间 = 从用户请求到可见输出的时间。
Latency = time delay before transfer or processing begins.
延迟 = 传输或处理开始前的等待时间。
Both should be tested under normal and peak load conditions.
两者都应在正常和峰值负载条件下进行测试。
4. Evaluation Criteria: Usability | 评估标准：可用性
Usability describes how easily and effectively a user can interact with a system. It is especially important for commercial systems where users have no formal training.
可用性描述用户与系统交互的容易程度和有效性。对于用户未经正式培训的商业系统，可用性尤为重要。
An evaluation of usability may consider learnability: how quickly a novice user can achieve basic tasks. It also considers memorability: whether a returning user can quickly regain proficiency after a period away.
可用性评估可能考虑易学性，即新手用户多快能完成基础任务；还考虑易记性，即用户离开一段时间后能否快速恢复熟练操作。
User error rate is another criterion. A system with a high frequency of accidental errors may be poorly designed. For example, placing a 'Delete account' button next to a 'Save' button could lead to costly mistakes.
用户错误率是另一个标准。频繁发生意外错误的系统可能设计不佳。例如，将“删除帐户”按钮放在“保存”按钮旁边可能导致代价高昂的错误。
Subjective user satisfaction is also measured through questionnaires and interviews. If users feel frustrated, they may abandon the system even if it is technically excellent.
主观用户满意度也通过问卷和访谈来衡量。如果用户感到沮丧，即使系统技术出色，他们也可能放弃使用。
5. Evaluation Criteria: Reliability and Availability | 评估标准：可靠性与可用性
Reliability is the probability that a system performs without failure over a specified period. It is often expressed as Mean Time Between Failures (MTBF). A high MTBF indicates a dependable system.
可靠性是系统在指定时间内无故障运行的概率。通常用平均故障间隔时间（MTBF）表示。高 MTBF 表示系统可靠。
Mean Time To Repair (MTTR) measures how quickly a system can be restored after a failure. Together, MTBF and MTTR can be used to calculate availability:
平均修复时间（MTTR）衡量系统故障后恢复的速度。MTBF 和 MTTR 可共同用于计算可用性：
Availability = MTBF ÷ (MTBF + MTTR)
可用性 = MTBF ÷ (MTBF + MTTR)
Availability is the proportion of time a system is operational and accessible. A server with 99.9% availability is down for approximately 8.77 hours per year, while 99.99% availability allows only about 52.6 minutes of downtime per year.
可用性是系统运行且可访问的时间比例。可用性为 99.9% 的服务器每年大约停机 8.77 小时，而 99.99% 的可用性每年仅允许约 52.6 分钟的停机时间。
In mission-critical systems, such as hospital patient monitoring or airline reservation systems, high availability is a mandatory requirement rather than a desirable feature.
在关键任务系统，如医院病人监护或航空订票系统中，高可用性是强制性要求，而非可选的优点。
6. Evaluation Criteria: Maintainability and Scalability | 评估标准：可维护性与可扩展性
Maintainability measures how easily a system can be modified to fix faults, improve performance, or adapt to changing requirements. Systems written in a modular style with clear documentation are generally more maintainable.
可维护性衡量系统被修改以修复故障、改进性能或适应变化需求的难易程度。采用模块化风格并具有清晰文档的系统通常更易于维护。
Scalability is the ability of a system to handle growing workloads. Vertical scaling means adding resources to a single machine, such as more RAM or a faster processor. Horizontal scaling means adding more machines to a distributed system.
可扩展性是系统处理不断增长的工作负载的能力。纵向扩展意味着向单台机器添加资源，例如更多内存或更快处理器。横向扩展意味着向分布式系统添加更多机器。
An evaluator should ask: what happens when the number of users doubles? Does performance degrade linearly, exponentially, or remain stable? A well-designed system should degrade gracefully, not collapse completely.
评估者应询问：当用户数量翻倍时会发生什么？性能是线性下降、指数下降还是保持稳定？设计良好的系统应优雅地降级，而不是完全崩溃。
Evaluating maintainability often involves examining code complexity metrics, such as cyclomatic complexity, and reviewing the quality of technical documentation.
评估可维护性通常涉及检查代码复杂度指标（如圈复杂度）以及审查技术文档的质量。
7. Evaluation Methods: Benchmarking | 评估方法：基准测试
Benchmarking involves running a standardised set of tests on a system to compare its performance against other systems or against established standards. These tests are called benchmarks.
基准测试是在系统上运行一组标准化测试，以将其性能与其他系统或既定标准进行比较。这些测试称为基准。
Common benchmarks include synthetic benchmarks, which use artificial workloads designed to stress specific components, and application-based benchmarks, which run real software such as database queries or video rendering tasks.
常见基准包括合成基准（使用旨在压测特定组件的人工工作负载）和基于应用程序的基准（运行真实软件，如数据库查询或视频渲染任务）。
For CPU performance, benchmarks may measure MIPS (millions of instructions per second) or FLOPS (floating-point operations per second). For disk systems, benchmarks measure read/write speeds and IOPS (input/output operations per second).
对于 CPU 性能，基准可测量 MIPS（每秒百万条指令）或 FLOPS（每秒浮点运算次数）。对于磁盘系统，基准测量读写速度和 IOPS（每秒输入/输出操作次数）。
1 FLOPS = one floating-point operation per second
1 MIPS = 10⁶ instructions per second
1 FLOPS = 每秒一次浮点运算
1 MIPS = 每秒 10⁶ 条指令
When comparing benchmarks, evaluators must ensure that test conditions are identical, including hardware configuration, operating system, and compiler settings. Otherwise, results may be misleading.
比较基准测试时，评估者必须确保测试条件完全相同，包括硬件配置、操作系统和编译器设置。否则结果可能具有误导性。
8. Evaluation Methods: Profiling and Monitoring | 评估方法：性能剖析与监控
Profiling is the dynamic analysis of a system while it is running. A profiler records information about which parts of the code are executed most frequently and how long each function or procedure takes.
性能剖析是在系统运行时进行的动态分析。剖析器记录代码哪些部分执行最频繁，以及每个函数或过程耗时多少。
Profiling results help developers identify bottlenecks. For instance, if a profiler shows that a sorting routine consumes 70% of execution time, then optimising that routine will yield the greatest improvement.
剖析结果帮助开发人员识别瓶颈。例如，如果剖析器显示排序例程消耗 70% 的执行时间，那么优化该例程将带来最大的改进。
Monitoring is a continuous or periodic observation of system metrics over time. Monitoring tools track CPU usage, memory consumption, network traffic, and error logs. They can alert administrators when thresholds are exceeded.
监控是对系统指标随时间进行持续或定期观察。监控工具跟踪 CPU 使用率、内存消耗、网络流量和错误日志。当阈值被超过时，它们可以提醒管理员。
System monitoring is especially important after deployment. A system that passes all tests may still fail under real-world traffic patterns, such as sudden spikes during a holiday sale.
系统监控在部署后尤为重要。通过所有测试的系统在真实世界流量模式下仍可能失败，例如假日促销期间的突然流量激增。
Profiling focuses on code-level performance during development.
性能剖析侧重于开发期间的代码级性能。
Monitoring focuses on system-level health after deployment.
监控侧重于部署后的系统级健康状态。
Both produce quantitative data suitable for comparison.
两者都产生适合比较的量化数据。
9. Evaluation Methods: User Feedback and Surveys | 评估方法：用户反馈与调查
Not every evaluation criterion can be measured automatically. User satisfaction, perceived ease of use, and emotional response require direct feedback from human users.
并非每个评估标准都可以自动测量。用户满意度、感知易用性和情感反应需要来自人类用户的直接反馈。
Questionnaires can be distributed to a sample of users after using the system. These may include Likert scale questions, where users rate statements from 'strongly agree' to 'strongly disagree'. Such data can be analysed statistically.
问卷可以在用户使用系统后分发给样本用户。这类问卷可能包含李克特量表问题，用户对陈述从“非常同意”到“非常不同意”进行评分。这些数据可以进行统计分析。
Interviews and focus groups provide richer qualitative data. They allow evaluators to ask follow-up questions and explore issues that questionnaires might miss.
访谈和焦点小组提供更丰富的定性数据。它们允许评估者提出后续问题，并探讨问卷可能遗漏的问题。
User observation involves watching users interact with the system in a controlled environment or in the field. Evaluators can record time taken to complete tasks, count errors, and note moments of confusion.
用户观察是在受控环境或现场观察用户与系统交互。评估者可以记录完成任务所需时间、统计错误次数，并记录困惑时刻。
One important principle is that feedback should be gathered from a representative sample, not only from technical experts. A system that satisfies programmers may frustrate ordinary end users.
一个重要原则是，反馈应从代表性样本中收集，而不仅仅来自技术专家。令程序员满意的系统可能让普通最终用户感到沮丧。
10. Evaluation Methods: Cost-Benefit Analysis | 评估方法：成本效益分析
Cost-benefit analysis compares the total costs of a system against the total benefits it delivers over its lifetime. It helps organisations decide whether to build, buy, or abandon a system.
成本效益分析将系统的总成本与其整个生命周期内带来的总收益进行比较。它帮助组织决定是构建、购买还是放弃系统。
Costs include development costs (staff salaries, equipment, software licences), operational costs (electricity, maintenance, support staff), and intangible costs such as employee training time.
成本包括开发成本（员工工资、设备、软件许可）、运营成本（电力、维护、支持人员）以及无形费用，例如员工培训时间。
Benefits may be tangible, such as increased sales or reduced labour costs, or intangible, such as improved customer satisfaction or better brand reputation.
收益可能是有形的，例如销售增长或劳动力成本降低；也可能是无形的，例如客户满意度提高或品牌声誉改善。
Return on Investment (ROI) is often calculated as:
投资回报率（ROI）通常计算为：
ROI = (Net Benefit ÷ Total Cost) × 100%
ROI = （净收益 ÷ 总成本） × 100%
If the ROI of a proposed system is lower than the interest rate available from keeping the money in a bank, the project may not be financially justified.
如果拟议系统的 ROI 低于将资金存入银行可获得的利率，那么该项目在财务上可能不合理。
11. Evaluation Methods: Inspection and Static Analysis | 评估方法：检查与静态分析
Static analysis evaluates a system without executing it. In software systems, this includes code reviews, walkthroughs, and formal inspections where developers examine source code line by line.
静态分析在不执行系统的情况下进行评估。在软件系统中，这包括代码审查、走查和正式检查，开发人员逐行检查源代码。
Automated static analysis tools can detect potential errors such as division by zero, null pointer dereferences, unreachable code, or style violations. These tools can process thousands of lines of code quickly.
自动化静态分析工具可以检测潜在错误，例如除零、空指针解引用、不可达代码或样式违规。这些工具可以快速处理数千行代码。
In hardware systems, inspection might involve visual checks of circuit boards, thermal testing, or using diagnostic tools to verify signal integrity. Non-destructive testing is preferred to avoid damaging the system.
在硬件系统中，检查可能涉及电路板的目视检查、热测试或使用诊断工具验证信号完整性。无损检测是首选，以避免损坏系统。
Inspection is particularly valuable for security evaluation. White-box security testing examines the internal structure of the code to identify vulnerabilities that an external black-box test might miss.
检查对安全评估尤为有价值。白盒安全测试检查代码内部结构，以识别外部黑盒测试可能遗漏的漏洞。
Static analysis is not a replacement for dynamic testing. Some bugs only appear when the system is running, such as race conditions in multi-threaded programs.
静态分析不能替代动态测试。有些错误只在系统运行时出现，例如多线程程序中的竞态条件。
12. Choosing the Right Evaluation Method | 选择正确的评估方法
No single evaluation method is sufficient for all situations. A comprehensive evaluation plan should combine multiple methods to cover both quantitative and qualitative criteria.
没有一种评估方法适用于所有情况。全面的评估计划应结合多种方法，以覆盖定量和定性标准。
Consider a hospital booking system. To evaluate it properly, an organisation should use benchmarking for response time, user questionnaires for usability, profiling for server resource usage, and cost-benefit analysis for financial viability.
以医院预约系统为例。为正确评估，组织应使用基准测试测量响应时间，使用用户问卷评估可用性，使用性能剖析分析服务器资源使用情况，并使用成本效益分析评估财务可行性。
| Criterion | Typical Method | Data Type |
|---|---|---|
| Efficiency | Benchmarking, profiling | Quantitative |
| Usability | Surveys, observation | Mixed |
| Reliability | Monitoring, failure logs | Quantitative |
| Maintainability | Static analysis, code review | Qualitative |
| Financial viability | Cost-benefit analysis | Quantitative |
In examination questions, you may be given a scenario and asked to recommend an evaluation method. You should justify your choice by linking the method to the specific criterion being assessed.
在考试题目中，你可能被给定一个情景，并被要求推荐一种评估方法。你应该通过将方法与被评估的具体标准联系起来来证明你的选择。
Remember that evaluation is iterative. After an evaluation identifies problems, developers should make improvements, and then re-evaluate the system to confirm that the changes have worked.
请记住，评估是迭代的。在评估发现问题之后，开发人员应进行改进，然后重新评估系统以确认更改已经生效。
In summary, system evaluation in A-Level Computer Science requires knowledge of criteria such as efficiency, response time, usability, reliability, maintainability, and scalability. The methods include benchmarking, profiling, monitoring, user feedback, cost-benefit analysis, and static inspection.
总而言之，A-Level 计算机科学中的系统评估需要理解效率、响应时间、可用性、可靠性、可维护性和可扩展性等标准。方法包括基准测试、性能剖析、监控、用户反馈、成本效益分析和静态检查。
A successful evaluation uses the right combination of methods, collects credible data, and feeds the results back into the development cycle for continuous improvement.
成功的评估使用正确的方法组合，收集可信数据，并将结果反馈到开发周期中以实现持续改进。
Published by TutorHao | Computer Science Revision Series | aleveler.com
更多咨询请联系16621398022（同微信）
或截图后用「扫一扫 → 相册」选择本图