5．4　软件维护

1．软件维护的定义

所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。我们可以通过描述软件交付使用后可能进行的四项活动，具体地定义软件维护。

1）改正性维护

因为软件测试不可能暴露出一个大型软件系统中隐藏的错误，所以必然会有改正性维护活动：在任何大型软件的使用期间，用户必然会发现程序错误，并且把它们遇到的问题报告给维护人员。我们把诊断和改正错误的过程称为改正性维护。

2）适应性维护

计算机科学技术领域的各个方面都在迅速进步，大约每过36个月就有新一代的硬件出现，经常推出新操作系统或旧系统的修改版本，时常增加或修改外部设备和其他系统部件；另一方面，应用软件的使用寿命却很容易超过10年，远远长于最初开发这个软件时的运行环境的寿命。因此，适应性维护也就是为了与变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动。

3）完善性维护

当一个软件系统顺利地运行时，常常出现完善性维护活动：在使用软件的过程中用户往往提出增加新功能或修改已有功能的建议，还可能提出一般性的改进意见。为了满足这类要求，需要进行完善性维护。这项维护活动通常占用软件维护工作的大部分时间。

4）预防性维护

当为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件时，出现了预防性维护活动。目前这项维护活动相对来说比较稀少。

从上述关于软件维护的定义不难看出，软件维护绝不仅限于纠正使用中发现的错误，事实上在全部维护活动中它们一般都是完善性维护。统计数据表明，完善性维护占全部维护活动的50%～66%，改正性维护占17%～21%，适应性维护占18%～25%。应该注意的是，上述的维护活动都必须应用整个软件配置，维护软件文档和维护软件的可执行代码是同样重要的。

2．维护的特点

1）结构化维护与非结构化维护的对比

如果软件配置的唯一成分是程序代码，那么维护活动将从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难。最终对程序代码所做的改动的后果是难以估量的：因为没有测试方面的文档，所以不可能进行回归测试。非结构化维护要付出巨大的代价，这种维护方式是没有使用良好定义的方法论开发出来的软件的必然结果。

如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特点及接口特点；估量要求的改动将带来的影响，并且计划实施途径，这种维护称为结构化维护。结构化维护评价文档，确定软件特点，然后修改设计并对所做的修改进行回归测试；最后，把修改后的软件再次交付使用。结构化维护是子软件开发早期应用软件工程方法论的必然结果。软件的完整配置虽然不能保证维护中没有问题，但是确实能减少精力的浪费，并且能提高维护的总体质量。

2）维护的代价

在过去的几十年中，软件的维护费用稳步上升。1970年，用于维护已有软件的费用只占软件总预算的35%～40%；1980年，上升为40%～60%；1990年，上升为70%～80%。

维护费用只不过是软件维护的最明显的代价，其他一些现在还不明白的代价将来可能更为人们所关注。因为可用的资源必须供维护任务使用，以致耽误甚至丧失了开发的良机，这是软件维护的一个无形的代价。其他无形的代价还有：当看似合理的有关改错或修改的要求不能及时满足时，将引起用户不满；由于维护时的改动，在软件中引入了隐藏的故障，从而降低了软件的质量；当必须把软件工程师调来从事维护工作时，将在开发过程中造成混乱。

软件维护的最后一个代价是生产效率的大幅度下降，这种情况在维护旧软件时常常遇到。用于维护工作的劳动可以分成生产性活动和非生产性活动。维护工作量的模型为

M＝P＋K×exp（c－d）

其中，M是维护用的总工作量，P是生产性工作量，K是经验常数，c是复杂程度（非结构化设计和缺少文档会增加软件的复杂程度），d是维护人员对软件的熟悉程度。

上述表达式表明，如果软件的开发途径不好（没有使用软件工程方法论），而且原来的开发者不能参加维护，那么维护工作量将呈指数地增加。

3）维护的问题

与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺点。在软件生存周期的头两个时期如果没有严格而又科学的管理和规划，必然会导致在最后阶段出现问题。这些问题概括如下。

（1）理解别人编写的程序通常是非常困难的，而且困难程度随着软件配置成分的减少而迅速增加。如果仅有程序代码而没有说明文档，则会出现严重的问题。

（2）需要维护的软件往往没有合格的文档，或者文档资料显著不足。认识到软件必须有文档仅仅是第一步，容易理解的并且与程序代码完成一致的文档才能真正有价值。

（3）当要求对软件进行维护时，不能指望由开发者给予仔细说明。由于维护阶段持续时间很长，因此当需要解释软件时，往往原来编写程序的人已经离开了。

（4）绝大多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理的设计方法论，否则修改软件既困难又容易产生差错。

（5）软件维护不是一项吸引人的工作，形成这种观念很大程度上是因为维护工作经常遭受挫折。

3．维护过程

维护过程本质上是修改和压缩了软件定义和开发的过程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作就已经开始了。首先必须建立一个维护组织，随后必须确定报告和评价的过程，而且必须为每个维护要求规定一个标准化的事件序列。此外，还应该建立一个适用于维护活动的记录保管过程，并且规定复审标准。

1）维护组织

每个维护要求都通过维护管理员转交给相应的系统管理员去评价，系统管理员被指定去熟悉一小部分产品程序，并对维护任务作出评价。

2）维护报告

应该用标准化的格式表达对所有软件的维护要求。软件维护人员通常给用户提供空白的维护要求表（软件问题报告表），这个表由要求维护活动的用户填写。

3）维护的事件流

不管维护类型如何，维护时都需要进行同样的技术工作，包括软件设计、复查、必要的代码修改、单元测试、集成测试、验收测试和复审。不同的维护强调的重点不同，但是途径相同。维护事件流的最后一个时间是复审，它再次检验软件配置的所有成分的有效性，并且保证事实上满足了维护要求表中的要求。

4）保存维护记录

对于软件生存周期的所有阶段，以前的记录保存都是不充分的，而软件维护则根本没有记录保存下来。维护记录应该记录下程序标识、源代码数量、维护类型等数据。可以利用这些维护记录构成一个维护数据库，方便对维护进行评价。

5）评价维护活动

根据维护工作的记录，可对维护工作定量度量，进一步可以作出关于开发技术、语言选择、维护工作量规划、资源分配等其他方面的决定，而且可以利用这样的数据去分析、评价维护任务。