2026年上半年软考高级系统分析师案例分析回忆重构卷

2026年上半年软考高级系统分析师案例分析回忆重构

说明：本卷根据多份回忆资料与案例知识点资料交叉验证整理而成。由于原始材料是回忆题，以下为“同考点重构版”，不声明为官方原题逐字复刻。案例分析题以材料、问题、参考答案和解析形式整理；图形题使用 Markdown 图片引用。

第1题

某企业的订单履约系统近期出现多起订单失效、客户投诉和利润下降问题。项目组收集到如下现象和原因线索：

(1) 合同中未规定未按期完成订单的后果；
(2) 订单已完成，但客户未及时知晓；
(3) 订单快到期时系统未通知客户，导致订单失效；
(4) 原料成本高，导致产品难以降价；
(5) 产品售价较高，客户大批量购买也无优惠；
(6) 财务人员未持续监控订单风险和价格风险。

项目组准备采用因果分析法和鱼骨图对上述问题进行分析。

【问题1】（6分）
请说明什么是因果分析法，并列举常见的因果分析方法。

答案：
因果分析法又称根因分析法，是从已经发生的问题或结果出发，逆向追溯导致该结果的直接原因、间接原因和根本原因的系统分析方法。它用于定位问题成因、归纳原因类别，并为后续改进措施提供依据。

常见方法包括：鱼骨图法、5Why 分析法、故障树分析法、因果矩阵、帕累托分析法等。

解析：
因果分析关注“为什么会发生”，不是简单记录现象。鱼骨图适合把原因按人员、方法、管理、技术、环境等类别展开；5Why 通过连续追问原因逼近根因；故障树分析适合从顶层故障逐层分解成基本事件；帕累托分析常用于识别少数关键原因。

【问题2】（8分）
请将材料中的 6 个原因归入鱼骨图的原因类别。

答案：

解析：
鱼骨图分类不要求唯一标准，但归类应能帮助定位改进责任。合同条款属于规则约束；通知缺失属于流程和系统能力问题；原料成本属于资源成本；批量无优惠属于销售策略；财务未监控则同时涉及人员职责和管理机制。

【问题3】（8分）
下列场景中，哪些适合使用因果分析法？哪些不适合？请说明理由。

(1) 系统分析阶段，预先排查可能存在的安全风险；
(2) 系统设计阶段，对比多个功能设计方案；
(3) 系统实施阶段，对比研发技术方案；
(4) 系统测试阶段，分析系统性能不足原因；
(5) 系统部署阶段，分析服务器经常出问题的原因；
(6) 系统试运行阶段，分析用户反馈“不好用”的原因；
(7) 测试过程中，分析接口测试多次失败的原因；
(8) 上线后，分析客户使用不方便的原因。

答案：
适合使用因果分析法的场景是：(4)、(5)、(6)、(7)、(8)。
不适合或不优先使用因果分析法的场景是：(1)、(2)、(3)。

解析：
因果分析法适合对已经发生或已经暴露的问题进行根因定位，如性能不足、服务器故障、用户体验差、接口测试失败等。它不适合替代方案选型、预先风险规划或技术路线比较；这些场景更适合风险分析、架构评估、成本收益分析、原型验证或专家评审。

第2题

某医院拟建设远程诊断系统。系统支持患者在线选择医生、提交问诊请求、查看处方和评价问诊；医生可以在线接诊并出具电子处方；管理员负责维护药品信息。系统建设过程中，分析人员绘制了用例图和时序图，并需要识别边界类、控制类和实体类。

【问题1】（11分）
请根据图中 A-K 的位置，从“患者、医生、更新个人信息、选择医生、在线接诊、出具电子处方、查看处方、评价问诊、维护药品、包含、扩展”中选择合适内容填空。

答案：

解析：
患者是发起问诊和查看结果的主要参与者，医生负责在线接诊和出具电子处方，管理员负责维护基础药品信息。“包含”表示基础用例必然执行的公共子功能；“扩展”表示在特定条件下可选发生的附加行为，如问诊结束后评价问诊。

【问题2】（6分）
时序图中出现“患者、医生详细信息页、问诊页面、诊断处理、医生、诊断记录”等对象。请按 BCE 模式识别边界类、控制类和实体类。

答案：

解析：
BCE 模式中，边界类负责系统与外部用户或外部系统的交互，通常是页面、接口、表单；控制类负责业务流程协调和调度；实体类负责承载需要持久化的业务数据，如患者、医生和诊断记录。

【问题3】（8分）
远程诊断完成后，系统需要通知患者 APP，并将诊断结果发送给汇总分析程序。请说明应采用同步调用还是消息队列，并给出理由。

答案：
建议采用消息队列进行异步通知。诊断主流程完成后，将“诊断完成”“处方已生成”等事件写入消息队列，由患者通知服务和汇总分析程序分别消费消息。患者 APP 可通过推送、站内信或 WebSocket 获得结果；汇总分析程序可异步消费诊断记录进行统计分析。

解析：
通知和统计分析属于诊断主流程之后的辅助处理，不应阻塞医生出具诊断结果。若使用同步 RPC，通知服务或分析程序故障可能拖慢甚至影响诊断流程。消息队列可以削峰填谷、降低耦合、支持失败重试和多消费者扩展，更适合通知、日志、统计等异步场景。

第3题

某在线教育平台保存用户信息、订购记录、直播授课记录和点播授课资源。平台业务分为直播授课和点播授课两类：

(1) 直播授课业务实时性强，要求 RPO 不超过 5 分钟，RTO 不超过 1 分钟；
(2) 点播授课业务可以接受小时级故障恢复；
(3) 平台需要在成本、数据一致性、运维复杂度和容灾演练方面选择合适方案。

【问题1】（8分）
请说明冷备、热备和双活的区别，并分别给出直播授课业务和点播授课业务的容灾建议。

答案：

直播授课业务建议采用双活或热备方案，优先保证 RTO 不超过 1 分钟、RPO 不超过 5 分钟。
点播授课业务可采用冷备或定期备份加异地恢复方案，以较低成本满足小时级恢复要求。

解析：
直播授课属于强实时业务，用户正在上课时故障影响大，不能接受长时间中断；点播授课容忍度更高，故障后延迟恢复影响较小。因此不能对所有业务采用同一高成本容灾等级，应按业务重要性分级设计。

【问题2】（8分）
请比较同步复制和异步复制，并结合数据一致性与经济性说明平台可采用的复制策略。

答案：

建议对直播授课的核心业务数据采用同步或半同步复制；跨地域容灾可采用近实时异步复制，确保 RPO 在 5 分钟内。点播资源、日志、统计等可采用异步复制或周期性备份。

解析：
同步复制能更好保障一致性，但会增加写入延迟和部署成本；异步复制经济性更好，适合对恢复点要求较宽松的数据。平台应按数据重要程度和业务恢复目标分层配置，不宜全部使用最高成本方案。

【问题3】（9分）
从成本、运维复杂度、定期演练必要性三个角度，说明容灾方案选型时应考虑的因素。

答案：
成本方面，应考虑机房、服务器、存储、网络专线、软件许可和人员成本。双活成本最高，热备次之，冷备最低。
运维复杂度方面，应考虑数据同步、故障检测、自动切换、回切、容量规划、版本一致性和监控告警。方案越实时，运维复杂度越高。
定期演练方面，应定期验证备份可用性、切换流程、RTO/RPO 是否达标、人员职责是否清晰，以及故障恢复后数据是否一致。

解析：
容灾不能只看技术指标。高等级容灾如果没有监控、演练和运维保障，实际故障时仍可能不可用。容灾选型应在业务连续性目标和可承受成本之间取得平衡。

第4题

某医院拟建设工单管理系统，系统功能包括：工单基础信息配置、工单提交与流转、消息通知、工单评价与回复、预警规则配置、工单扫描和预警发送。系统需要支持 Web、APP 和小程序多端访问，并支持邮件、站内信、实时消息等多种通知方式。

系统设计人员提出两种实现方案：李工建议使用 RPC 同步调用，张工建议使用 RabbitMQ 消息队列实现异步解耦。

【问题1】（8分）
请说明 RabbitMQ 消息队列的特点、基本工作原理和适用场景。

答案：
RabbitMQ 是一种消息队列中间件，主要特点是异步解耦、削峰填谷、可靠投递、支持发布订阅、支持确认机制和持久化。
基本工作原理是：生产者将消息发送到交换机，交换机根据路由规则把消息投递到队列，消费者从队列中获取消息并处理，处理成功后返回确认；若处理失败，可重试、重新入队或进入死信队列。
适用场景包括：消息通知、邮件发送、站内信、工单预警、日志采集、统计分析、跨系统事件分发等。

解析：
消息队列适合把主流程和非核心后续处理拆开。例如工单提交成功后，不必等待邮件、短信、统计分析都执行完成，可以先提交工单并写入消息，由后续消费者异步处理。

【问题2】（8分）
请比较 HTTP 与 WebSocket 的连接方式和适用场景。

答案：

解析：
HTTP 简单、通用、易于缓存和代理，适合普通业务请求。WebSocket 建立长连接后服务端可主动推送消息，适合实时性要求高的通知场景。

【问题3】（8分）
请说明图中 1、2、3、4 分别代表的内容，并给出各自作用。

答案：

解析：
多端系统通常先经过统一接入层，再进入应用服务或微服务。数据库处理持久化，缓存提升读取性能，消息队列处理异步事件和跨服务通知。

【问题4】（6分）
在 RPC 同步调用和消息队列之间，你更推荐哪种方案实现消息通知、工单评价、预警和统计分析？请说明理由。

答案：
更推荐消息队列。工单提交、工单流转等核心事务可使用同步调用保证即时结果；消息通知、评价后续处理、预警分发、统计分析等辅助功能应通过消息队列异步处理。

解析：
RPC 同步调用实时性强，但调用方必须等待被调用方返回，下游服务故障可能影响主流程。消息队列可降低耦合，支持异步处理、失败重试、削峰填谷和多消费者扩展，更适合通知、预警、统计等事件驱动场景。

第5题

某企业计划研发一款边缘智能终端，用于图像采集和人脸识别。设备部署环境存在 PoE 供电和电池供电两种情况。项目组需要在 RTOS 与 Linux 之间选择操作系统，并在多个处理器方案中选择合适芯片。

候选处理器如下：

【问题1】（10分）
请从实时性、安全性、资源占用、启动速度、典型应用等方面比较 RTOS 和 Linux。

答案：

解析：
RTOS 适合实时控制和资源受限场景；Linux 适合复杂业务、网络协议丰富、驱动和 AI 生态要求较高的场景。边缘智能终端若以图像处理和人脸识别为主，Linux 通常更便于开发和扩展。

【问题2】（10分）
结合处理速度、价格、功耗和性价比，为图像采集和人脸识别设备选择处理器，并说明理由。

答案：
推荐选择方案 B：集成 NPU 的 ARM SoC。

理由如下：

解析：
A 方案功耗低但难以承担人脸识别推理；C、D 性能强但功耗和成本过高，不利于边缘大规模部署。B 方案能够兼顾算力、功耗和成本，是该场景的较优选择。

【问题3】（5分）
若项目组最终选择 Linux，请说明选择 Linux 的 5 个好处。

答案：

1. 驱动和硬件生态丰富，便于接入摄像头、网卡、存储和外设。
2. 网络协议栈成熟，适合远程管理、数据上传、OTA 升级和云端对接。
3. AI 与图像处理生态完善，便于使用 OpenCV、推理框架和 NPU SDK。
4. 多进程、多线程和文件系统能力完善，适合复杂应用开发。
5. 社区和厂商支持较多，便于调试、维护、安全补丁和后续扩展。

解析：
Linux 的优势不在硬实时控制，而在复杂应用生态和工程效率。对于人脸识别、图像采集、网络传输和边缘智能推理等任务，Linux 能显著降低开发和维护难度。