软件维护是软件生命周期的最后一个阶段。

它的任务是：维护软件的正常运行，不断改进软件的性能和质量，为软件的进一步推广应用和更新替换做积极工作。

软件维护所需的工作量非常大，一般说来，大型软件的维护成本高达开发总成本的四倍左右。目前，软件开发组织把60%以上的工作量用于维护自己的软件上。

软件交付使用问题：

• 软件验收测试以后，就标志着软件设计开发阶段的结束。
• 而软件交付用户使用，才真正标志漫长的维护阶段的开始。

软件交付使用就是新系统和旧系统的转换。

• 旧系统可能是人工作业系统，也可能是某个旧的计算机系统。
• 软件交付应该是一个过程，而不是一个突然事件，软件的交付使用应尽可能平稳过渡，不影响生产或工作，新系统逐步安全地取代旧系统。

一、交付使用前的工作

1）将旧系统的数据转换到新系统（如数据库数据）；

2）新系统调试完成并加载入机器，准备运行；

3）将有关资料（如使用说明）转交给用户；

4）对用户做适当的培训。

二、软件交付使用的方式

1）直接方式

直接方式是用新系统直接替换旧系统，没有过渡。

优点：转换简单，费用最省。

缺点：风险大。

由于新系统没有承担过实际工作，可能会出现意想不到的问题，甚至出现程序设计错误。因此，实际应用时，采取一些措施，以便新系统一旦出错，旧系统能够恢复运行。

直接方式不适用于一些关系重大的系统。

2）并行方式

一些关系重大的软件产品在验收测试后，并不立即投入生产性运行，而是同时运行新系统和旧系统，以比较处理结果，这就是并行方式。

优点：

• A. 可以对系统进行全面测试，减少了新系统失灵带来的风险，因为旧系统也仍然存在；
• B. 用户也能够有一段熟悉新系统的时间。

缺点：所需费用较高，双系统要投入更多的人力财力。

3）逐步方式

逐步方式是将软件分期，部分地交付使用。这种方式克服了上面两种方式的缺点，既能防止直接转换产生的危险性，又能减少并行方式的费用。

但是这种方法使得整个系统中一部分是旧系统，一部分是新系统，所以必须考虑好它们的相互配合问题和接口问题。

实际应用中，常常是混合以上几种方法。对系统不重要的部分采用直接方式，对系统重要部分采用并行方式，使系统平稳交付使用。

8.1 软件维护的定义

8.1.1 软件维护的原因

通常要求进行软件维护的原因有三种：

• 1）改正在特定使用条件下暴露出来的一些潜在程序错误或设计缺陷；
• 2）因在软件使用过程中数据环境发生变化（如所要处理的数据发生变化）或处理环境发生变化（如硬件或软件操作系统等发生变化），需要修改软件，以适应这种变化；
• 3）用户和数据处理人员在使用时常提出改进现有功能、增加新功能、以及改善总体性能的要求，为满足这些要求，需要修改软件。

8.1.2 软件维护的类型

1）改正性维护

交付给用户使用的软件，即使通过严格的测试，仍可能有一些潜在的错误在用户使用的过程中发现和修改。诊断和改正错误的过程称为改正性维护。

2）适应性维护

随着计算机的飞速发展，新的硬件系统和外部设备时常更新和升级，一些数据库环境、数据输入/输出方式、数据存储介质等也可能发生变换。为了使软件适应这些环境变化而修改软件的过程叫做适应性维护。

3）完善性维护

在软件投入使用过程中，用户可能还会有新的功能和性能要求，可能会提出增加新功能、修改现有功能等要求。为了满足这类要求而进行的维护称为完善性维护。

4）预防性维护

为了改进软件未来的可维护性或可靠性，或者为了给未来的改进奠定更好的基础而进行的修改，称为预防性维护。这种维护活动在实践中比较少见。

在各类维护中，完善性维护占软件维护工作的大部分。

根据国外的数据统计表明，完善性维护占全部维护活动的50%～66%，改正性维护占17%～21%，适应性维护占18%～25%，其它维护活动占4%左右。

8.2 软件维护的特点

8.2.1 结构化维护与非结构化维护的差别

1. 非结构化维护

如果软件配置的唯一成分是代码，则维护从评价程序代码开始。对软件结构、数据结构、系统接口、设计约束等则常产生误解，不能进行回归测试，维护代价大。

2. 结构化维护

有完整的软件配置，维护从评价设计文档开始，确定软件结构、性能和接口特点，先修改设计，接着修改代码，再进行回归测试。

8.2.2 软件维护的代价

1. 有形代价与无形代价

软件维护的代价表现为有形代价和无形代价。

有形代价指软件维护的费用开支。

70年代，用于软件维护的费用只占软件总预算的30%～40%，80年代上升到60%左右，90年代许多软件项目的维护经费预算达到了80%。

无形代价：

• 1）当一些看起来合理的要求不能及时满足时，会引起用户的不满；
• 2）改动软件可能会引入新的错误，使软件质量下降；
• 3）把许多软件工程师调去从事维护工作，势必影响开发工作。

2. 软件维护工作量模型(了解)

软件维护所花费的工作量，一部分用于生产性活动，如分析、评价、修改设计、编写程序等；另一部分用于非生产性活动，如理解代码的含义、解释数据结构和接口特点等。

Belady和Lehman提出了一种维护工作量模型(了解)：M=P+Ke(c-d)

其中：

• M：用于维护工作的总工作量；
• P：生产性工作量；
• K：经验常数；
• c：因缺乏好的设计和文档而导致软件复杂性的度量；
• d：维护人员对软件熟悉程度的度量。

上述模型指出：如果使用了不好的软件开发方法，原来参加开发的人员或小组不能参加维护，则工作量和成本将按指数级增加。

8.2.3 软件维护的典型问题

1）如果维护时只有程序代码而没有注释说明，维护起来就相当困难；

2）由于软件维护阶段时间长，软件开发人员经常流动，所以在维护时，不可能所有的维护工作都依靠原来的开发人员。这会使得维护工作量增加；

3）软件没有足够的文档资料，或者程序修改后与文档资料不一致；

4）绝大多数软件在设计时没有考虑将来的修改，所以建议采用功能独立的模块化设计原则，增加软件的可维护性；

5）软件维护被许多人视为一种毫无吸引力的工作，因为维护工作常常受到挫折。

要缓解以上典型问题，建议采用软件工程的方法来开发程序。

8.3 软件维护过程

1. 维护组织

2. 维护报告

根据软件问题报告（维护要求），作出的软件修改报告包含的信息主要有：

• 1）满足维护要求表中提出的要求所需要的工作量；
• 2）维护要求的性质；
• 3）这项要求的优先次序；
• 4）与修改有关的事后数据（如测试数据等）。

3. 维护的事件流

4. 保存维护记录

1）程序标识；

2）源语句数；

3）机器指令数；

4）使用的程序设计语言；

5）程序安装的日期；

6）自安装以来程序运行次数；

7）自安装以来程序失效次数；

8）程序变动的层次和标识；

9）因程序变动而增加的源语句数；

10）因程序变动而删除的源语句数；

11）每个改动耗费的人时数；

12）程序改动的日期；

13）软件工程师的名字；

14）维护要求表的标识；

15）维护类型；

16）维护开始和完成的日期；

17）累计用于维护的人时数；

18）与完成的维护相联系的纯效益。

5. 评价维护活动

可以从以下方面度量维护工作：

• 1）每次程序运行平均失效的次数；
• 2）用于每一类维护活动的总人时数；
• 3）平均每个程序、每种维护类型所做的程序变动数；
• 4）维护过程中增加或删除一个源语句平均花费的人时数；
• 5）维护每种语言平均花费的人时数；
• 6）一张维护要求表的平均周转时间；
• 7）不同维护类型所占的百分比。

8.4 软件的可维护性

8.4.1 决定软件可维护性的因素

软件可维护性是：维护人员理解、改正和改进软件的难易程度。

一个软件的可维护性，主要由五个因素决定：

1. 可理解性

可理解性表现为外来读者理解软件的结构、接口、功能和内部过程的难易程度。

影响软件可理解性的重要因素有：模块化、结构化设计、详细的设计文档资料、源代码内部文档、良好的程序设计语言等。

2. 可测试性

在设计开发阶段应该注意尽量把软件设计成容易测试和容易诊断的，可用的测试工具和调试工具对测试和诊断非常重要。

3. 可修改性

软件的可修改程度与软件设计阶段采用的原则和策略是直接相关的。如：模块的耦合、内聚、控制范围和作用范围、局部化程度都直接影响软件的可修改性。

4. 可移植性

5. 可重用性

决定软件可维护性的最终因素是软件设计阶段所采用的方法，以及软件文档资料的好坏。

提高软件的可维护性是软件工程的一个重要目标。

8.4.2 文档

1. 用户文档

1）功能描述；

2）安装文档；

3）使用手册；

4）参考手册；

5）操作员指南；

2. 系统文档

SVN 软件： 配置修改记录、代码版本管理。

8.4.3 可维护性复审

测试结束时进行正式的可维护性复审，称为配置复审。

目的是：保证软件配置的所有成分是完整的、一致的和可理解的。

8.4.4 影响维护工作量的因素

在软件的维护过程中，花费的大量工作量会直接影响软件的成本。

因此，应当考虑有哪些因素会影响软件维护的工作量，应该采取什么维护策略，才能有效地维护软件并控制维护的成本。

影响软件维护工作量的因素有：

• 1）系统大小。系统越大，功能越复杂，理解掌握起来就越困难，需要的维护工作量越大。
• 2）程序设计语言。使用功能强的程序设计语言可以控制程序的规模。语言的功能越强，生成程序所需的指令数就越少；语言的功能越弱，实现同样功能所需的语句就越多，程序就越大，维护起来就越困难。
• 3）系统年龄。老系统比新系统需要更多的维护工作量。许多老系统在当初并未按照软件工程的要求进行开发，没有文档，或文档太少，或者在长期的维护中许多地方与程序不一致，维护起来困难较大。
• 4）数据库技术的应用。使用数据库工具，可有效地管理和存储用户程序中的数据，可方便地修改、扩充报表。数据库技术的使用可以减少维护工作量。
• 5）先进的软件开发技术。在软件开发时，如果使用能使软件结构比较稳定的分析与设计技术（如面向对象分析、设计技术），可以减少一定的工作量。
• 6）其它。如，应用的类型、数学模型、任务的难度、IF嵌套深度等等都会对维护工作量产生一定的影响。

8.5 预防性维护

进行预防性维护主要原因：

• （1）对于旧系统而言，维护一行原代码的代价可能是最初开发该行源代码代价的14－40倍；
• （2）重新设计软件体系结构（程序和数据结构）使用最新的设计理念，对将来的维护有较大帮助；
• （3）原有的旧系统可作为软件原型使用，能提高开发效率。

对旧程序维护的做法：

• 1）反复多次做修改程序的尝试；
• 2）先通过仔细分析程序，尽可能多地掌握程序内部工作细节，再有效地修改；
• 3）用软件工程方法重新设计、编码和测试需要变更的软件部分；是局部再工程；
• 4）以软件工程方法为指导，对程序全部重新设计、编码和测试。(是软件再工程 / 预防性维护)

8.6 软件再工程过程

活动以线性顺序发生，但并非总是这样。

对于任意一个特定循环，可在完成任意一个活动后终止。

该模型定义的6类活动：

1. 库存目录分析

包含每个应用系统的信息，如：名称、构建日期、修改次数、过去18个月报告的错误、用户数量、文档质量、预期寿命，等。从中选出再工程的候选者。

2. 文档重构

（1）如果一个程序走向生命终点，不再经历变化，则保持现状；

（2）重构只针对当前正在修改的软件部分。

3. 逆向工程

逆向工程是一个恢复设计结果的过程，从程序代码中抽取数据结构、体系结构和处理过程的设计信息。

4. 代码重构

分析源代码，标注出与结构化程序设计概念不符的部分，重构它的代码，测试重构代码并更新代码。

5. 数据重构

当数据结构较差时，进行再工程。如以文件方式保存数据变为以数据库方式存储。

6. 正向工程

也称革新或改造，即应用软件工程的原理、概念、技术和方法来重新开发现有系统。

小结

◇ 软件维护手册

主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明，便于软件的维护。

◇ 软件问题报告

指出软件问题的登记情况，如日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。

◇ 软件修改报告

软件产品投入运行以后，发现了需对其进行修正、更改等问题，应将存在的问题、修改的考虑以及修改的影响作出详细的描述，提交审批。

软件工程开发中其它重要的文档

◇ 开发进度月报

该月报系软件人员按月向管理部门提交的项目进展情况报告，报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。

◇ 项目开发总结报告

软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力，此外，还需对开发工作做出评价，总结出经验和教训。

◇ 用户操作手册

本手册详细描述软件的功能、性能和用户界面，使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节。

重点

维护类型

非结构化维护和结构化维护

软件维护的有形代价与无形代价