【软考高级·系统分析师全链路通关实战】第 43 篇系统转换、运行与维护——遗留系统与系统评价本系列定位面向有开发经验、从零备考软考高级「系统分析师」的工程师以《系统分析师教程第 2 版》为主线按「综合知识 → 案例分析 → 论文」三科组织需求工程与 UML 建模深拆60 篇带你从考试小白到三科同过。本篇你将学到系统转换四策略直接、并行、分段、试点——风险与成本对比及适用场景案例高频论证题遗留系统演化四策略淘汰、改造、集成、继承——按「技术水平 × 业务价值」四象限判定高频必考系统维护四类改正性、适应性、完善性、预防性——给场景判类型综合必考系统评价性能评价指标与经济效益评价云诊通实战医院业务的并行转换方案论证论文素材学完本篇模块八收官——从需求到实现测试再到上线运维软件工程的完整生命周期考点链在你的知识地图上闭合。考点热力表知识点综合知识案例分析论文转换四策略对比与选择论证★★★★★★★★遗留系统四象限策略★★★★★★维护四类判定★★★★★系统评价性能/效益★★★★★一、系统转换新系统如何接管旧系统1.1 四种转换策略策略做法风险成本适用直接转换旧系统停止新系统立即接管最高最低新系统简单或旧系统已不可用并行转换新旧同时运行一段时期核对一致后切换最低最高双份运行核心业务、安全性要求高分段转换分阶段分部门逐块切换中中大型系统、可按模块切分试点转换先选一个试点部门/院区运行成功后推广较低中多分支机构、同质业务记忆钩子风险从直接→分段递减成本从直接→并行递增——风险与成本基本互换没有免费午餐。1.2 云诊通实战医院业务并行转换论证论文素材场景云诊通第 11 月推广上线业主要求互联网医院服务不能中断、处方数据不能出错第 03 篇合规约束处方实时上报监管。同时7 家医院分布在 3 个地市各院原有电话/窗口预约流程仍在使用。论证结构结论 三理由 一风险结论核心域预约挂号、电子处方采用并行转换外围域报告查询、随访采用试点转换牵头医院先上1 个月后推广 6 家成员医院。理由一风险不可承受处方与挂号是医疗核心业务直接转换一旦出错就是患者安全与监管事件新旧并行一个月双轨数据核对每日对账报表保证数据一致后切换。理由二分段降成本全业务并行成本过高7 家院区双轨人力外围域先行试点可验证流程再推广把并行的高成本压缩在核心域。理由三组织接受度并行期为医院工作人员提供适应窗口降低抵触——转换不只是技术事件更是组织变革事件。风险与对策并行期双录入增加一线负担、可能出现口径不一致对策是明确以新系统为准、旧系统只读兜底并设每日对账员。这套「核心并行 外围试点」的组合论证可直接平移到案例题「为某系统选择转换策略并说明理由」。核心·处方挂号外围·报告随访云诊通上线决策业务域风险等级?并行转换新旧双轨一个月·每日对账试点转换牵头医院先行·一个月后推广对账一致后旧系统停用试点复盘修正后全面切换二、遗留系统演化策略四象限判定2.1 两个维度、四种策略按技术水平高低代码质量、可维护性与业务价值高低分四象限遗留系统判定技术水平 × 业务价值高技术 高价值继承继续使用为主局部优化高技术 低价值淘汰直接下线替换低技术 高价值改造重构或重写保业务延续低技术 低价值集成封装屏蔽以接口融入新系统象限策略一句话高技术、高价值继承系统还好用且重要继续用高技术、低价值淘汰质量好但没人在乎下线低技术、高价值改造业务离不开但代码烂重构/再工程第 19 篇低技术、低价值集成又烂又不重要包一层接口融入新体系注意「集成」象限的逻辑不值得投入改造但其中部分功能仍有数据或流程价值用封装适配第 40 篇适配器模式的系统级应用接入新系统其余任其淘汰。云诊通语境某成员医院的旧 LIS 接口即低技术低价值外围但报告数据仍有查询价值——封装成 REST 数据接口接入平台而不动其内部。三、系统维护四类判定必考类型触发原因云诊通例子改正性维护修错——开发期未发现的缺陷修复「医保结算金额四舍五入错误」适应性维护适应环境变化—— OS 升级、法规变更、接口改造监管上报接口协议改版后的接口适配完善性维护按用户要求增加功能、改善性能占比最大应医生要求增加「常用语回复模板」预防性维护为未来可维护性主动重构预见处方量增长提前重构处方编号服务判定口诀错了改改正、变了适适应、要了加完善、未来防预防。综合题干扰项常把「用户提出的需求变更」混入适应性维护——用户主动要的功能改进是完善性外部环境逼着改才是适应性。四、系统评价4.1 性能评价指标衔接第 07 篇响应时间、吞吐量、资源利用率、可用度 A MTBF/(MTBFMTTR)。系统评价中的考法偏概念组合「从功能、性能、可靠性、易用性、可维护性多维度评价」。4.2 经济效益评价衔接第 05 篇工程经济成本效益分析——投资回收期、净现值 NPV、内部收益率、ROI。云诊通论文素材上线一年后评价预约挂号线上化率 78%、平均候诊时间从 42 分钟降至 25 分钟、处方流转周期缩短 30%按 680 万投资折算回收期约 2.6 年论文「成效」段的标准写法先业务指标、后经济指标。4.3 维护与评价的组织事实系统运行阶段日常维护中完善性维护占比最大约 50%、改正性约 20%、适应性约 25%、预防性约 5%——这个占比数字综合考过且反直觉多数人以为修 bug 最多。4.4 评价的组织方式系统评价按时机分**事前立项论证、事中阶段评审、事后上线后评价**三类本篇讨论的是事后评价。事后评价通常由业主牵头组织评价依据是立项时的建设目标与需求规格第 29 篇 SRS 的验收标准章节在此闭环评价报告同时服务于两个目的向业主交付「值不值」的结论以及为运维期维护优先级排序提供输入——云诊通上线后第一份评价报告就直接催生了「报告查询响应优化」这条完善性维护需求的最高优先级。五、真题风格演练维护四类判定题组维护类型判定每年必考难点全在「干扰场景」上。下面这组云诊通运维期真实事件把四类维护与最容易混淆的边界一网打尽——每条先自己判再看解析。#运维事件判定判定依据1用户报告「打印处方笺时医生签章位置偶发错位」定位为前端样式缺陷修复改正性开发期未暴露的缺陷行为与规格不符2医保局新版结算接口 10 月启用平台改造对接逻辑适应性外部环境变化法规/接口逼着改3药师反馈审方界面字段太小按其要求调整放大并增加筛选完善性用户主动提出的易用性改进4运维监测到处方表索引膨胀重组索引、归档历史数据预防性为未来性能主动治理当前无故障5监管新规要求处方留存期限从 5 年改 10 年调整归档策略适应性法规变更——注意与 3 区分不是用户「想要」6修复「闰年 2 月 29 日随访计划生成异常」改正性边界条件缺陷仍是「错了改」7应院长要求给运营看板新增「科室问诊量趋势」图表完善性新增功能需求来自用户要求8预见流感季流量提前扩容缓存并将报告查询改读写分离预防性面向未来的主动性能加固三条判定铁律案例题直接引用看动因不看结果同样是改代码「用户要」→ 完善性「环境变」→ 适应性「出错了」→ 改正性「防未来」→ 预防性。动因判断法一击即中。「需求变更」≠ 适应性维护综合题最爱的陷阱。用户提出的功能改进走完善性只有操作系统升级、法规改版、第三方接口改造这类系统外部变化才归适应性。主动与被动之分改正性、适应性都是「被动响应」缺陷已发生、环境已变化完善性、预防性都有「主动成分」——预防性甚至没有直接触发方完全由维护方前瞻发起。占比口诀再记一遍完善过半约 50%、适应四分之一、改正五分之一、预防最少约 5%。延伸一问案例进阶题目若问「维护活动如何组织管理」标准采分点是四条——维护申请与审批流程区分维护类型并评估影响范围、维护实施与验证回归测试必备防止修一处坏一片第 42 篇、维护记录与档案更新配置管理第 31 篇基线思想的运维延续、维护效果评审以维护工作量与缺陷率度量维护质量第 14 篇过程度量的落点。把维护从「判定题」延伸到「管理题」正是系统分析师区别于程序员的考察意图。真题风格自测题1. 风险最低但运行成本最高的系统转换策略是 。A. 直接转换 B. 并行转换 C. 分段转换 D. 试点转换2. 旧系统立即停止、新系统马上接管的策略是 。A. 直接转换 B. 并行转换 C. 分段转换 D. 试点转换3. 大型系统可按模块逐步切换宜采用 。A. 直接转换 B. 并行转换 C. 分段转换 D. 全部一次性上线4. 遗留系统「技术水平高、业务价值高」时宜采取的策略是 。A. 淘汰 B. 改造 C. 继承 D. 集成5. 遗留系统「技术水平低、业务价值高」时宜采取的策略是 。A. 淘汰 B. 改造重构或重写 C. 继承 D. 直接下线6. 遗留系统「技术水平低、业务价值低」但部分数据仍有用时宜采取 。A. 继承 B. 全面重写 C. 集成封装屏蔽后接入新系统 D. 无策略可选7. 为适应操作系统升级和法规变更而修改系统属于 。A. 改正性维护 B. 适应性维护 C. 完善性维护 D. 预防性维护8. 修复开发阶段未发现、运行期暴露的缺陷属于 。A. 改正性维护 B. 适应性维护 C. 完善性维护 D. 预防性维护9. 应用户要求增加「常用语回复模板」功能属于 。A. 改正性维护 B. 适应性维护 C. 完善性维护 D. 预防性维护10. 为提高未来可维护性、预防故障而主动重构属于 。A. 改正性维护 B. 适应性维护 C. 完善性维护 D. 预防性维护11. 在系统维护的四种类型中通常占比最大的是 。A. 改正性维护 B. 适应性维护 C. 完善性维护 D. 预防性维护12. 云诊通对预约挂号与处方域采用新旧双轨运行一个月再切换该策略是 。A. 直接转换 B. 并行转换 C. 分段转换 D. 试点转换13. 案例题问「为医疗核心业务系统选择转换策略并论证」最不应遗漏的论证维度是 。A. 只考虑成本最低 B. 业务风险承受度 数据一致性核对 组织接受度与退出机制 C. 只考虑上线最快 D. 只看开发团队偏好14. 可用度 A 的计算公式是 。A. MTBF/(MTBFMTTR) B. MTTR/(MTBFMTTR) C. MTBF×MTTR D. 1/MTTR参考答案1.B 2.A 3.C 4.C 5.B 6.C 7.B 8.A 9.C 10.D 11.C 12.B 13.B 14.A维护四类口诀错了改、变了适、要了加、未来防占比最大是完善本篇小结知识点核心内容转换四策略直接风险最高成本最低、并行反之、分段大系统切块、试点先点后面云诊通方案核心域并行 外围域试点组合每日对账 旧系统只读兜底遗留四象限高技高值继承、高技低值淘汰、低技高值改造、低技低值集成封装接入维护四类改正修错、适应应变、完善加需占比最大、预防未来系统评价性能响应/吞吐/可用度衔接第 07 篇 经济NPV/回收期衔接第 05 篇模块八收官41 实现与选型 → 42 测试方法 → 43 转换运维生命周期考点链闭合下篇预告第 44 篇Web 应用系统分析与设计进入模块九「案例实践六大场景」Web 架构演进、高性能设计缓存/CDN/负载均衡/异步、Web 安全设计与云诊通问诊高峰性能分析实战。如果本篇内容对你有帮助欢迎点赞收藏有任何疑问欢迎在评论区交流。