第8章 维护
基本任务：
是保证软件在一个相当长的时期能够正常运行。
软件维护需要的工作量很大，60%以上的人力用于维护已有的软件，随着投入使用的软件数量增多和使用寿命延长，这个百分比还在持续上升。最终导致软件开发组织没有余力开发新的软件。
软件工程的目的：
要提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。
8.1 软件维护的定义
软件维护：
在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。
可以通过以下4项活动，具体地定义软件维护。
•四种维护类型：
改正性维护
适应性维护
完善性维护
预防性维护
1.改正性维护
在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。
这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。
为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程。
2.适应性维护
在使用过程中，外部环境、数据环境可能发生变化。
外部环境（新的硬、软件配置）
数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）
适应性维护：为使软件适应这种变化，而去修改软件的过程。
3.完善性维护
•在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。
•完善性维护：
为了满足上述要求，需要修改或再开发软件而进行的完善性的维护活动。以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。
•完善性维护不一定是救火式的紧急维修，可以是有计划、有预谋的一种再开发活动。
4.预防性维护
•预防性维护：
为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础而修改软件的维护活动。
•预防性维护的定义：
采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试的过程。
国外的统计数字表明：
完善性维护占全部维护活动的50%～66%，
改正性维护占17%～21%，
适应性维护占18%～25%，
其他维护活动只占4%左右。
完善性维护占了几乎一半的工作量。
可见：
大部分维护工作是改变和加强软件，不是纠错。
8.2 软件维护的特点
8.2.1 结构化维护与非结构化维护差别巨大
1. 非结构化维护
如果软件配置的惟一成分是程序代码，
•那么维护活动从艰苦地评价程序代码开始。
•没有设计文档及测试文档。
非结构化维护需要付出很大代价，这种维护方式是没有使用良好的方法学开发出来的软件的必然结果。
2. 结构化维护
如果有一个完整的软件配置存在，
•那么维护工作从评价设计文档开始；
•估量要求的改动将带来的影响，并且计划实施途径。
•然后修改设计并且对所做的修改进行仔细复查。
•编写相应的源程序代码；
•使用在测试说明书中包含的信息进行回归测试；
•把修改后的软件再次交付使用。
8.2.2 维护的代价高昂
•软件维护活动所花费的工作占整个生存期工作量的70%以上。
在漫长的软件运行过程中需要不断对软件进行修改，以改正新发现的错误、适应新的环境和用户新的要求，这些修改需要花费很多精力和时间，而且有时会引入新的错误。
•维护费用是软件维护的最明显的代价，还有一些无形的代价。
无形的代价还有：
•可用的资源必须供维护任务使用，以致耽误甚至丧失了开发的良机。
•改错或修改的不及时，引起的用户不满；
•由于维护时的改动，在软件中引入了潜伏的错误，从而降低了软件的质量；
•把软件工程师调去从事维护工作，在开发过程中造成的混乱。
•生产率的大幅度下降，尤其在维护旧程序时常常遇到。
维护工作量的一个模型：M = P + K × exp(c-d)
其中：
• M是维护用的总工作量，
• P是生产性工作量（分析等必要的过程） ，
• K是经验常数，
• c是复杂程度(非结构化设计和缺少文档都会增加软件的复杂程度)，
• d是维护人员对软件的熟悉程度。
模型表明：
如果软件的开发途径不好(没有使用软件工程方法学)，而且原来的开发人员不能参加维护工作，那么维护工作量和费用将指数地增加。
8.2.3 维护的问题很多
存在于没采用软件工程思想开发出来的软件中：
（1） 仅有程序代码没有说明文档；。
（2） 缺少容易理解的并且和程序代码完全一致的文档；
（3） 不能指望由开发人员给我们仔细说明软件。由于维护阶段持续的时间很长，写程序的人已经不在了。
（4） 绝大多数软件在设计时没有考虑将来的修改。没有使用模块独立的原理去的设计，使修改软件既困难又容易发生差错。
所以，应采用软件工程思想来开发软件
8.3 软件维护过程
• 先建立一个维护组织；
• 确定报告和评价的过程；
• 为每个维护要求规定一个标准化的事件序列；
• 建立一个适用于维护活动的记录保管过程；
• 规定复审标准。
1. 维护组织
对于每个维护要求：
•通过维护管理员转交给相应的系统管理员去评价。
系统管理员对维护任务做出评价之后，
•由变化授权人决定应该进行的活动。
图8.1描绘了上述组织方式。
目的：在维护活动开始之前就明确维护责任。
图8.1 维护组织
2. 维护报告
• 应该用标准化的格式表达所有软件维护要求。
• 软件维护人员通常给用户提供空白的维护要求表——有时称为软件问题报告表。
这个表格由要求维护活动的用户填写。
由维护管理员和系统管理员评价用户提交的维护要求表。
3. 维护的事件流
图8.2描绘了由一项维护要求而引出的一串事件。
•首先应该确定要求进行的维护的类型。
•改正性维护要求：
估量错误的严重程度；
是一个严重的错误，在系统管理员的指导下分派人员，立即开始问题分析过程；
错误并不严重，与其他的软件开发任务一起统筹安排。
•适应性维护和完善性维护要求：
应该确定每个维护要求的优先次序；
安排要求的工作时间；
如果优先次序非常高，可能立即开始维护工作。
软件维护工作流程
4. 保存维护记录
①程序标识；②源语句数； ③机器指令条数；
④使用的程序设计语言；⑤程序安装的日期；
⑥自从安装以来程序运行的次数；
⑦自从安装以来程序失效的次数；
⑧程序变动的层次和标识；
⑨因程序变动而增加的源语句数；
因程序变动而删除的源语句数； 每个改动耗费的人时数； 程序改动的日期； 软件工程师的名字； 维护要求表的标识； 维护类型； 维护开始和完成的日期； 累计用于维护的人时数； 与完成的维护相联系的纯效益。
5. 评价维护活动
从下述7个方面度量维护工作：
(1) 每次程序运行平均失效的次数；
(2) 用于每一类维护活动的总人时数；
(3) 平均每个程序、每种语言、每种维护类型所做的程序变动数；
(4) 维护过程中增加或删除一个源语句平均花费的人时数；
(5) 维护每种语言平均花费的人时数；
(6) 一张维护要求表的平均周转时间；
(7) 不同维护类型所占的百分比。
由此做出关于开发技术、语言选择、维护工作量规划、资源分配等方面的决定。
8.4 软件的可维护性
定义： 维护人员理解、改正、改动或改进这个软件的难易程度。
提高可维护性是软件开发阶段各个时期的关键目标。
8.4.1 决定软件可维护性的因素
维护：就是在软件交付使用后进行的修改。
•修改之前必须理解待修改的对象，
•修改之后应该进行必要的测试，以保证所做的修改是正确的。
•如果是改正性维护，还必须预先进行调试以确定错误的具体位置。
因此，决定软件可维护性的因素主要有下述5个：
可理解性，可测试性，可修改性，可移植性，
可重用性
1. 可理解性
•可理解性：外来读者理解软件的结构、功能、接口和内部处理过程的难易程度。
•影响因素：
模块化（模块结构良好，高内聚，松耦合）、详细的设计文档、结构化设计、程序内部的文档和良好的高级程序设计语言等等。
2. 可测试性
•可测试性：论证程序正确性的容易程度。
•模块的环形复杂度可度量它的可测试性。
模块的环形复杂度越大，可执行的路径就越多，全面测试它的难度就越高。
•影响因素：
良好的文档，软件结构、测试工具和调试工具，以前测试时设计的测试过程。
3. 可修改性
可修改性：软件容易修改的程度。
影响因素：耦合、内聚、信息隐藏、局部化、控制域与作用域的关系等等。
4. 可移植性
可移植性：把程序从一种计算环境（硬件配置和操作系统）转移到另一种计算环境的难易程度。
对策：
把与硬件、操作系统及其他外部设备有关的程序代码集中放到特定的程序模块中，受环境变化影响的仅有少数程序模块，从而降低修改的难度。
5. 可重用性
重用（reuse）：同一事物不做修改或稍加改动就在不同环境中多次重复使用。
使用可重用的构件来开发软件，可以提高软件的可维护性：
• 软件中使用的可重用构件越多，软件的可靠性越高，改正性维护需求越少。
• 很容易修改可重用的软件构件使之再次应用在新环境中，因此，软件中使用的可重用构件越多，适应性和完善性维护也就越容易。
8.4.2 文档
文档：是影响软件可维护性的决定因素。
大型软件系统在长期的使用过程中必然会经受多次修改，所以文档比程序代码更重要。
文档分类：
•系统文档：描述系统设计、实现和测试等一系列和系统实现有关的文档。
•用户文档：描述系统功能和使用方法，并不关心这些功能怎样实现。包括：
功能描述；安装文档；使用手册；参考手册；操作员指南。
用户文档应包括的5方面内容：
(1) 功能描述，说明系统能做什么；
(2) 安装文档，说明怎样安装这个系统以及怎样使系统适应特定的硬件配置；
(3) 使用手册，通过丰富例子说明怎样使用常用的系统功能，及用户操作错误时怎样恢复和重新启动；
(4) 参考手册，详尽描述用户可以使用的所有系统设施及使用方法，解释系统可能产生的各种出错信息的含义；
(5) 操作员指南(如果需要的话)，说明操作员应该如何处理使用中出现的各种情况。
8.4.3 可维护性复审
•在软件工程过程的每一个阶段都应该努力提高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。
从需求分析到设计与编码等各阶段。
•在完成了每项维护工作之后，都应该对软件维护本身进行仔细认真的复审。
•维护应该针对整个软件配置，不应该只修改源程序代码。
8.5 预防性维护
产生背景:
存在这样一些程序：
•体系结构和数据结构都很差，
•文档不全甚至完全没有文档，
•对曾经做过的修改也没有完整的记录。
•但仍然在为用户服务。
怎样满足用户对这类程序的维护要求呢？
有以下几种做法可供选择：
（1） 反复多次地做修改程序的尝试，与不可见的设计及源代码“顽强战斗”，以实现所要求的修改；
该做法很盲目，通常人们采用后3种做法。
（2） 通过仔细分析程序尽可能多地掌握程序的内部工作细节，以便更有效地修改它；
（3） 在深入理解原有设计的基础上，用软件工程方法重新设计、重新编码和测试那些需要变更的软件部分；
（4） 以软件工程方法学为指导，对程序全部重新设计、重新编码和测试，为此可以使用CASE工具（逆向工程和再工程工具）来帮助理解原有的设计。
•由Miller提出的。
•定义：“把今天的方法学应用到昨天的系统上，以支持明天的需求。”
依据：
（1） 维护一行源代码的代价可能是最初开发该行源代码代价的14~40倍；
（2） 重新设计软件体系结构（程序及数据结构）时使用了现代设计概念，它对将来的维护可能有很大的帮助；
依据：
（3） 由于现有的程序版本可作为软件原型使用，开发生产率可大大高于平均水平；
（4） 用户具有较多使用该软件的经验，因此，能够很容易地搞清新的变更需求和变更的范围；
（5） 利用逆向工程和再工程的工具，可以使一部分工作自动化；
（6） 在完成预防性维护的过程中可以建立起完整的软件配置。
8.6 软件再工程过程
过程模型如图8.3所示，定义了6类活动。
再工程范型是一个循环模型。每个活动都可能被重复，过程可以在完成任意一个活动之后终止。
图8.3 软件再工程过程模型
下面简要地介绍该模型所定义的6类活动。
1. 库存目录分析
•每个软件组织都应该保存其拥有的所有应用系统的库存目录。
•该目录包含关于每个应用系统的基本信息（例如，应用系统的名字，最初构建它的日期，已做过的实质性修改次数，过去18个月报告的错误，用户数量，安装它的机器数量，它的复杂程度，文档质量，整体可维护性等级，预期寿命，在未来36个月内的预期修改次数，业务重要程度等）。
•库存目录分析：分析哪些需要进行再工程过程。
有3类程序：
（1） 预定将使用多年的程序；
（2） 当前正在成功地使用着的程序；
（3） 在最近的将来可能要做重大修改或增强的程序。
2. 文档重构
老程序固有的特点是缺乏文档。处理方法：
（1） 如果一个程序是相对稳定的，正在走向终点，保持现状，不建文档。
（2） 只针对系统中当前正在修改的那些部分建立完整文档。随着时间流逝，将得到一组有用的和相关的文档。
（3） 如果某应用系统是完成业务工作的关键，而且必须重构全部文档，也设法把文档工作减少到必需的最小量。
3. 逆向工程
•软件的逆向工程：是分析程序以便在比源代码更高的抽象层次上创建出程序的某种表示的过程；
•逆向工程是一个恢复设计结果的过程；
•逆向工程工具从现存的程序代码中抽取有关数据、体系结构和处理过程的设计信息。
4. 代码重构
•代码重构是最常见的再工程活动。
•某些老程序具有比较完整、合理的体系结构，但是，个体模块的编码方式却是难于理解、测试和维护的，可进行代码重构。
•重构过程：分析源代码→标注需重构部分→重构→复审、测试→更新文档。
•重构并不修改整体的程序体系结构，它仅关注个体模块的设计细节以及在模块中定义的局部数据结构。
•如果重构扩展到模块边界之外，并涉及软件体系结构，则重构变成了正向工程。
5. 数据重构
•对数据体系结构差的程序很难进行适应性修改和增强；
•数据体系结构比源代码本身对程序的长期生存力有更大影响；
•由于数据体系结构对程序体系结构及算法有很大影响，对数据的修改必然会导致体系结构或代码层的改变。
•当数据结构较差时，应该对数据进行再工程。
6. 正向工程
•正向工程也称为革新或改造；
•不仅从现有程序中恢复设计信息，而且使用该信息去改变或重构现有系统，以提高其整体质量。
•被再工程的软件不仅重新实现现有系统的功能，而且加入了新功能和提高了整体性能。
8.7 小结
维护是软件生命周期的最后一个阶段，也是持续时间最长代价最大的一个阶段。
软件维护通常包括4类活动：
为了纠正在使用过程中暴露出来的错误而进行的改正性维护；
为了适应外部环境的变化而进行的适应性维护；
为了改进原有的软件而进行的完善性维护；
以及为了改进将来的可维护性和可靠性而进行的预防性维护。
软件的可理解性、可测试性、可修改性、可移植性和可重用性，是决定软件可维护性的基本因素。
软件重用技术能从根本上提高软件可维护性。
软件生命周期每个阶段的工作都和软件可维护性有密切关系。因此，在软件生命周期的每个阶段都必须充分考虑维护问题，并且为软件维护预做准备。
文档是影响软件可维护性的决定因素，甚至比程序代码更重要。文档必须和程序代码同时维护。
虽然由于维护资源有限，目前预防性维护在全部维护活动中仅占很小比例，但在条件具备时应该主动地进行预防性维护。
预防性维护实质上是软件再工程。
