Appearance
系统转换
遗留系统处置策略
遗留系统是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统
遗留系统:不能进行修改和演化以满足新业务需求的信息系统。特点:性能落后、技术过时、无文档、难维护。

| 策略 | 条件 |
|---|---|
| 淘汰 | 低业务价值 + 低系统质量 |
| 继承 | 高业务价值 + 低系统质量 |
| 改造 | 高业务价值 + 高系统质量 |
| 集成 | 低业务价值 + 高系统质量 |
系统转换方式
🎯 一句话结论:系统转换有4种方式,并行转换最安全(新旧系统同时运行一段时间)。
| 方式 | 说明 | 风险 |
|---|---|---|
| 直接转换 | 直接切换到新系统 | 高 |
| 并行转换 | 新旧系统同时运行一段时间,验证后再切换 | 低 |
| 分段转换 | 按模块/区域逐步切换 | 中 |
| 渐进式转换 | 逐步演进替换 | 中 |
数据转换与迁移:将数据从旧数据库迁移到新数据库中。要在新系统中尽可能的保存旧系统中合理的数据结构,才能降低迁移的难度。
也有三种方法:系统切换前通过工具迁移、系统切换前采用手工录入、系统切换后通过新系统生成。
软件维护概述

🎯 一句话结论:维护分4种 — 改正性(修BUG)、适应性(适应新环境)、完善性(加功能)、预防性(用今天方法优化昨天系统为明天需求)。
| 类型 | 触发原因 | 考试关键词 |
|---|---|---|
| 改正性维护 | 发现性能缺陷/Bug 需要诊断改正 | "发现性能缺陷进行诊断和改正" |
| 适应性维护 | 外部环境变化(新OS、新硬件) | "适应新操作系统" |
| 完善性维护 | 用户提出新功能/性能要求 | "增加新功能" |
| 预防性维护 | 主动预防未来可能的问题 | "把今天的方法学用于昨天的系统以满足明天的需要" |
⚠️ 易错辨析:「改正性」是修复已有错误(被动),「预防性」是主动预防未来问题。
影响软件维护的因素: 文档质量(是决定因素)、软件复杂度、人员变动等。 软件可维护性度量: 外部用 MTTR(平均修复时间),内部用软件复杂性间接度量。 软件维护阶段占整个生命周期 60% 以上的时间。
净室软件工程
以数学和统计学为基础,强调从源头预防缺陷,而非先开发再测试修复。
核心理念: 预防胜于修复、统计质量控制、零缺陷开发。
应用技术: 统计过程控制(增量开发中监控质量)、基于函数的规范与设计、正确性验证(编码前验证)、统计测试和软件认证。
缺点: 理论化(需数学知识)、耗时(正确性验证困难)、不进行传统模块测试可能不现实。