目录
一、遗留系统（Legacy System）
定义：
特点：
演化策略（基于价值与技术评估）：
高水平 - 低价值：
高水平 - 高价值：
低水平 - 低价值：
低水平 - 高价值：
二、系统转换（System Transition）
定义：
转换计划：
三、系统维护（System Maintenance）
可维护性评价指标：
维护类型：
四、系统评价（System Evaluation）
评价分类：
评价指标：
组成部分：
评价对象：
经济学角度：
真题示例：
一、遗留系统（Legacy System）
定义：
遗留系统是指基本无法修改或演化以满足新业务需求的信息系统。
特点：
- 功能局限：完成部分业务管理，但无法完全满足需求，很少涉及经营决策。
- 技术落后：采用过时技术（如主机/终端、小型机、汇编语言、文件系统而非数据库）。
- 维护困难：通常是大型系统，已融入企业运作，修改成本高。
- 文档缺失：未采用现代开发方法，缺乏文档，难以理解。
演化策略（基于价值与技术评估）：
-
高水平 - 低价值：
- 描述：系统技术水平处于高水平，但业务价值低。
- 策略：集成。即通过一定方式将此类系统与其他系统进行整合，以更好地发挥其技术优势。
-
高水平 - 高价值：
- 描述：技术水平和业务价值均处于高水平。
- 策略：改造。对这类系统进行优化、升级等改造操作，以持续保持其优势，适应不断变化的需求。
-
低水平 - 低价值：
- 描述：技术水平和业务价值都低。
- 策略：淘汰。这类系统由于各方面价值较低，可考虑停止使用，以避免资源浪费。
-
低水平 - 高价值：
- 描述：技术水平低，但业务价值高。
- 策略：继承。即继承其业务价值，可能需要在后续通过技术手段对其进行改进等操作。
二、系统转换（System Transition）
定义：
- 新系统取代旧系统的过程，需考虑交接问题。
转换计划：
| 类型 | 描述 | 适用场景 | 优缺点 |
|---|---|---|---|
| 直接转换 | 新系统直接取代旧系统 | 系统简单或旧系统已不可用 | 风险大，但节省成本 |
| 并行转换 | 新旧系统并行运行，新系统试运行后取代 | 大型系统 | 风险小，但耗费资源，数据转换复杂 |
| 分段转换 | 分期分批转换（子系统逐一替换） | 大型项目 | 耗时，需协调接口问题 |
| 数据迁移 | 将旧数据库迁移至新数据库（工具迁移、手工录入、新系统导入） | 系统切换前后 | 需确保数据一致性 |
三、系统维护（System Maintenance）
可维护性评价指标：
- 易分析性：诊断缺陷或失效原因的能力。
- 易改变性：实现修改（代码、设计、文档）的能力。
- 稳定性：避免修改导致意外结果的能力。
- 易测试性：确认已修改软件的能力。
- 维护性依从性：符合相关标准的能力。
维护类型：
| 类型 | 描述 |
|---|---|
| 正确性维护 | 修复已发现的Bug。 |
| 适应性维护 | 因外部环境变化（如政策、技术）被动调整系统。 |
| 完善性维护 | 主动增加新功能或优化性能。 |
| 预防性维护 | 预防未来可能出现的故障。 |
四、系统评价（System Evaluation）
评价分类：
- 立项评价：开发前的可行性分析。
- 中期评价：阶段评审或重大变故时评估。
- 结项评价：正式运行后是否达到预期目标的综合评估。
评价指标：
-
组成部分：
- 人（用户需求、运行效果）
- 机（系统质量、技术条件）
-
评价对象：
- 开发方：关注系统质量与技术。
- 用户方：关注需求与运行质量。
- 外部环境：社会效益指标。
-
经济学角度：
- 系统成本、效益、财务指标。
真题示例：
对于遗留系统的评价框架如下图所示，那么处于“高水平、低价值”区的遗留系统适合于采用的演化策略为（ ）。
A. 淘汰 B.继承 C.改造 D.集成
集成，即通过一定方式将此类系统与其他系统进行整合，以更好地发挥其技术优势。
以下关于软件维护和可维护性的叙述中，不正确的是（ ）。
A. 软件维护要解决软件产品交付用户之后运行中发生的各种问题
B. 软件的维护期通常比开发期长得多，其投入也大得多
C. 进行质量保证审查可以提高软件产品的可维护性
D. 提高可维护性是在软件维护阶段考虑的问题
可维护性应在软件开发的全生命周期（需求分析、设计、编码等阶段）中考虑，而非仅在维护阶段。其他选项描述正确：
-
A：维护阶段解决运行中的问题（如缺陷、新需求等）。
-
B：维护期通常比开发期长，成本更高。
-
C：质量保证审查（如代码评审、测试）能间接提升可维护性。
某企业由于外部市场环境和管理需求的变化对现有软件系统提出新的需求，则对该软件系统进行的维护属于______维护。
A. 正确性 B. 完善性 C. 适应性 D. 预防性
适应性维护指为使软件适应外部环境（如新硬件、政策、市场需求）变化而进行的修改。若题目描述的是“新增功能”，则属于完善性维护，但明确提到“外部变化”，故更倾向适应性维护。
