第八章 软 件 维 护 普通人轻视软件维护工作， 会失掉极其宝贵的机会； 维护人员轻视软件维护工作， 会失掉本应精彩的人生； 老板轻视软件维护工作， 会丢掉大片本来属于自己的市场……

第八章 软件维护 8.1 软件维护的定义 软件维护 ---- 就是在软件已经交付使用之后，为保证软件在相当长的时期能够正常运作所进行的软件活动。 维护的类型有四种： 改正性维护 适应性维护 扩充与完善性维护 预防性维护

改正性维护 --- Corrective Maintenance 在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。 这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。 为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，所进行的诊断和改正错误的过程就叫做改正性维护。

适应性维护 --- Adaptive Maintenance 在使用过程中， 外部环境（新的硬、软件配置） 数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质） 可能发生变化。 为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。

扩充与完善性维护 --- Perfective Maintenance 在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。 为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。 这种情况下进行的维护活动叫做扩充与完善性维护。

预防性维护 --- Preventive Maintenance 预防性维护是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。 预防性维护定义为：采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。

各种维护所占比例: 改正性维护 17%～ 21% 其它维护 4 % 适应性维护 18%～ 25% 扩充与完善性维护 50% ～ 60%

系统大小：系统越大，理解掌握起来越困难。系统越大，所执行功能越复杂。因而需要更多的维护工作量。 8.2 软件维护的特点 -- 影响维护工作量的因素 系统大小：系统越大，理解掌握起来越困难。系统越大，所执行功能越复杂。因而需要更多的维护工作量。 程序设计语言：使用强功能的程序设计语言可以控制程序的规模。语言的功能越强，生成程序的模块化和结构化程度越高，所需的指令数就越少，程序的可读性越好。

系统年龄： 老系统随着不断的修改，结构越来越乱； 维护人员经常更换，程序又变得越来越难于理解 许多老系统在当初并未按照软件工程的要求进行开发，因而没有文档，或文档太少。 在长期的维护过程中文档在许多地方与程序实现变得不一致，在维护时就会遇到很大困难。 数据库技术的应用：使用数据库，可以简单而有效地管理和存储用户程序中的数据，还可以减少生成用户报表应用软件的维护工作量。

先进的软件开发技术：在软件开发时，若使用能使软件结构比较稳定的分析与设计技术，及程序设计技术，如面向对象技术、复用技术等，可减少大量的工作量。 其它： 应用的类型 数学模型 任务的难度 开关与标记、IF嵌套深度、索引或下标数等 对维护工作量都有影响。 许多软件在开发时并未考虑将来的修改，为软件的维护带来许多问题。

维护成本 有形的软件维护成本是花费了多少钱，无形的维护成本有更大的影响。 可用的资源必须供维护任务使用,以致耽误甚至丧失开发的良机; 一些合理的修复或修改请求不能及时安排，使得客户不满意； 变更的结果引入新的故障，使得软件整体质量下降； 把软件人员抽调到维护工作中，干扰了软件开发工作。

维护工作量的模型 M 是维护中消耗的总工作量 P 是生产性工作量 K 是一个经验常数 c 是因缺乏好的设计和文档而导致复杂性的度量 d 是维护人员对软件熟悉程度的度量 模型指明，如果使用了不好的软件开发方法（未按软件工程要求做），原来参加开发的人员或小组不能参加维护，则工作量（及成本）将按指数级增加。

采用软件工程方法至少可部分地解决与维护有关的每一个问题。 8.2.3 维护中的典型问题 (1) 难以跟踪软件版本的进化过程,软件的变化未在文档中反映出来. (2) 难以跟踪软件的创建过程. (3) 难以读懂他人程序. (4) 无文档或不全. (5) 软件人员流动性大. (6) 设计时未考虑修改需要,修改困难. 维护工作无吸引力,缺乏成就感. 采用软件工程方法至少可部分地解决与维护有关的每一个问题。

8.3 软件维护过程 维护过程本质上是修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。 8.3 软件维护过程 维护过程本质上是修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。 为了有效地进行软件维护，应事先就开始做组织工作。 首先建立维护的机构 申明提出维护申请报告的过程及评价的过程 为每一个维护申请规定标准的处理步骤 建立维护活动的记录保管，并规定复审的标准

1、维护机构 除了较大的软件开发公司外，通常在软件维护工作方面，并不保持一个正式的组织机构。 虽然不要求建立一个正式的维护机构，但是在开发部门确立一个非正式的维护机构则是非常必要的。

每个维护要求都通过维护管理员转交给相应的系统管理员去评价（系统管理员是被指定去熟悉一小部分产品程序的技术人员）。 系统管理员对维护任务做出评价之后，由变化授权人决定应该进行的活动。

2. 维护报告 应该用标准化的格式表达所有软件维护申请（要求）。 维护申请报告或称软件问题报告，由申请维护的用户填写。 用户必须完整地说明产生错误的情况，包括输入数据、错误清单以及其它有关材料。 如果申请的是适应性维护或完善性维护，用户必须提出一份修改说明书，列出所有希望的修改。

维护申请报告将由维护管理员和系统管理员来研究处理。 他们应相应地做出软件修改报告，指明： 所需修改变动的性质； 申请修改的优先级； 为满足某个维护申请报告，所需的工作量 预计修改后的状况. 软件修改报告应提交给变化授权人（修改负责人），经批准后才能开始进一步安排维护工作。

3. 维护的事件流

尽管维护申请的类型不同，但都要进行同样的技术工作。 修改软件需求说明 修改软件设计 设计评审 对源程序做必要的修改 单元测试 集成测试( 回归测试) 确认测试 软件配置评审等。

在每次软件维护任务完成后进行情况评审，对以下问题做一总结： (1) 在目前情况下，设计、编码、测试中的哪一方面可以改进 在每次软件维护任务完成后进行情况评审，对以下问题做一总结： (1) 在目前情况下，设计、编码、测试中的哪一方面可以改进? (2) 哪些维护资源应该有但没有? (3) 工作中主要的或次要的障碍是什么? (4) 从维护申请的类型来看是否应当有预防性维护? 情况评审对将来的维护工作如何进行会产生重要的影响。

4、维护档案记录 ①程序标识； ②源语句数； ③机器指令条数； ④使用的程序设计语言； ⑤程序安装的日期； ⑥自从安装以来程序运行的次数； ⑦自从安装以来程序失效的次数； ⑧程序变动的层次和标识； ⑨因程序变动而增加的源语句数； ⑽ 因程序变动而删除的源语句数； ⑾ 每个改动耗费的人时数； ⑿ 程序改动的日期； ⒀ 软件工程师的名字； ⒁ 维护要求表的标识； ⒂ 维护类型； ⒃ 维护开始和完成的日期； ⒄ 累计用于维护的人时数； ⒅ 与完成的维护相联系的纯效益。

5、维护评价 评价维护活动比较困难，因为缺乏可靠的数据。 如果维护的档案记录做得比较好，可以得出一些维护“性能”方面的度量值。 (1) 每次程序运行平均失效的次数； (2) 用于每一类维护活动的总人时数； (3) 平均每个程序、每种语言、每种维护类型所做的程序变动数； (4) 维护过程中增加或删除一个源语句平均花费的人时数； (5) 维护每种语言平均花费的人时数； (6) 一张维护要求表的平均周转时间； (7) 不同维护类型所占的百分比。 根据对维护工作定量度量的结果，可以做出关于开发技术、语言选择、维护工作量规划、资源分配及其他许多方面的决定，而且可以利用这样的数据去分析评价维护任务。

程序修改的步骤及修改的副作用(自学) 在软件维护时，必然会对源程序进行修改。 通常对源程序的修改不能无计划地仓促上阵，为了正确、有效地修改,需要经历以下三个步骤。 分析和理解程序 修改程序 重新验证程序

分析和理解程序 经过分析，全面、准确、迅速地理解程序是决定维护成败和质量好坏的关键。在这方面，软件的可理解性和文档的质量非常重要。 理解程序的功能和目标； 掌握程序的结构信息，即从程序中细分出若干结构成分。如程序系统结构、 控制结构、数据结构和输入／输出结构等；

为了容易地理解程序，要求自顶向下地理解现有源程序的程序结构和数据结构，为此可采用如下几种方法： 了解数据流信息，即涉及到的数据来源何处，在哪里被使用； 了解控制流信息，即执行每条路径的结果； 理解程序的操作(使用)要求； 为了容易地理解程序，要求自顶向下地理解现有源程序的程序结构和数据结构，为此可采用如下几种方法：

1. 分析程序结构图 (1) 搜集所有存储该程序的文件，阅读这些文件，记下它们包含的过程名，建立一个包括这些过程名和文件名的清单； (2) 分析各个过程的源代码，建立一个直接调用矩阵D或调用树。若过程 i 调用过程 j，则D[i][j]＝1，否则D[i][j]＝0。

(3) 建立过程的间接调用矩阵I，即直接调用矩阵D的传递闭包 I＝D1∪D2∪D3∪…∪Dn 其中，n是所包含的过程总数. 例如，过程 i 调用 j，j 调用 k， 则 D[i][j]＝1，D[j][k]＝1， I[i][k]＝1。 (4) 分析各个过程的接口，估计更改的复杂性。

2. 数据跟踪 (1) 建立各层次的程序级上的接口图，展示各模块或过程的调用方式和接口参数； (2) 利用数据流分析方法，对过程内部的一些变量进行跟踪。可获得有关数据在过程间如何传递，在过程内如何处理等信息。对于判断问题原因特别有用。在跟踪的过程中可在源程序中间插入自己的注释。

3. 控制跟踪 控制流跟踪可采用符号执行或实际动态跟踪的方法，了解数据如何从一个输入源到达输出点的。 4. 充分阅读和使用源程序清单和文档，分析现有文档的合理性。 5. 充分使用由编译程序或汇编程序提供的交叉引用表、符号表、以及其它有用的信息。 6. 如有可能，积极参加开发工作。

修改程序 对程序的修改，必须事先做出计划，有预谋地、周密有效地实施修改。 1. 设计程序的修改计划 程序的修改计划要考虑人员和资源的安排。小的修改可以不需要详细的计划，而对于需要耗时数月的修改，就需要计划立案。

在编写有关问题解决的方案时，必须充分描述修改作业的规格说明。  规格说明信息：数据修改、处理修改、作业控制语言修改、系统之间接口的修改等；  维护资源：新程序版本、测试数据、所需软件、计算机时间等；  人员；  支持：纸面、计算机媒体等。

通常，可采用自顶向下的方法，在理解程序的基础上， (1) 研究程序的各个模块、模块的接口、及数据库，从全局的观点，提出修改计划。 (2) 依次地把要修改的、以及那些受修改影响的模块和数据结构分离出来。为此，要  识别受修改影响的数据；  识别使用这些数据的程序模块；

 对于上面程序模块，按是产生数据、修改数据、还是删除数据进行分类；  识别对这些数据元素的外部控制信息；  识别编辑和检查这些数据元素的地方；  隔离要修改的部分；

(3) 详细地分析要修改的、以及那些受变更影响的模块和数据结构的内部细节，设计修改计划，标明新逻辑及要改动的现有逻辑。 (4) 向用户提供回避措施。用户的某些业务因软件中发生问题而中断，为不让系统长时间停止运行，需把问题局部化，在可能的范围内继续开展业务。 可以采取的措施有：

① 查找问题原因，可能情况有：  意外停机  安装的期限到期  系统运行中发现错误 ② 如果弄清了问题的原因，可通过临时修改或改变运行控制以回避在系统运行时产生的问题。

2. 修改代码，以适应变化 在修改时，要求： (1) 正确、有效地编写修改代码； (2) 要谨慎地修改程序，尽量保持程序的风格及格式，要在程序清单上注明改动的指令； (3) 不要删除程序语句，除非完全肯定它是无用的； (4) 不要试图共用程序中已有的临时变量或工作区，为了避免冲突或混淆用途，应设置自己的变量；

(5) 插入错误检测语句； (6) 在修改过程中做好修改的详细记录，消除变更中任何有害的副作用（波动效应）； 3. 修改程序的副作用 所谓副作用是指因修改软件而造成的错误或其它不希望发生的情况。副作用有三种：修改代码的副作用、修改数据的副作用、文档的副作用。

(1) 修改代码的副作用 在修改源代码时，都可能引入错误。例如，删除或修改一个子程序、删除或修改一个标号、 删除或修改一个标识符、改变程序代码的时序关系、改变占用存储的大小、改变逻辑运算符、修改文件的打开或关闭、改进程序的执行效率，以及把设计上的改变翻译成代码的改变时，都容易引入错误。

(2) 修改数据的副作用 在修改数据结构时，有可能造成软件设计与数据结构不匹配，因而导致软件出错。 数据副作用就是修改软件信息结构导致的结果。 容易导致设计与数据不相容的错误可以有： 重新定义局部的或全局的常量

数据副作用可以通过交叉引用表加以控制。把数据元素、记录、文件和其它结构联系起来。 重新定义记录或文件的格式 增大或减小一个数组或高层数据结构的大小 修改全局或公共数据 重新初始化控制标志或指针 重新排列输入／输出或子程序的参数 数据副作用可以通过交叉引用表加以控制。把数据元素、记录、文件和其它结构联系起来。

(3) 文档的副作用 对数据流、软件结构、 模块逻辑或任何其它有关特性进行修改时，必须对相关技术文档进行相应修改。否则会导致文档与程序功能不匹配，缺省条件改变，新错误信息不正确等错误。使得软件文档不能反映软件的当前状态。 对于用户来说，软件事实上就是文档。

如果对可执行软件的修改不反映在文档里，就会产生文档的副作用。 对交互输入的顺序或格式进行修改，如果没有正确地记入文档中，就可能引起重大的问题。 过时的文档内容、索引和文本可能造成冲突，引起用户失败和不满。 因此，必须在软件交付之前对整个软件配置进行评审，以减少文档的副作用。

为了控制因修改而引起的副作用，要做到： (1) 按模块把修改分组； (2) 自顶向下地安排被修改模块的顺序； (3) 每次修改一个模块； (4) 对于每个修改了的模块，在安排修改下一个模块之前，要确定这个修改的副作用。可以使用交叉引用表、存储映象表、执行流程跟踪等。

重新验证程序 在将修改后的程序提交用户之前，需要进行充分的确认和测试，以保证整个修改后程序的正确性。 静态确认 修改软件，伴随着引起新的错误的危险。为了能够做出正确的判断，验证修改后的程序至少需要两个人参加。要检查：

(1) 修改是否涉及到规格说明. 修改结果是否符合规格说明. 有没有歪曲规格说明. (2) 程序的修改是否足以修正软件中的问题 (1) 修改是否涉及到规格说明? 修改结果是否符合规格说明? 有没有歪曲规格说明? (2) 程序的修改是否足以修正软件中的问题? 源程序代码有无逻辑错误? 修改时有无修补失误? (3) 修改部分对其它部分有无不良影响(副作用)? 对软件进行修改，常常会引发别的问题，有必要检查修改的影响范围。

计算机确认 在进行了以上确认的基础上，用计算机对修改程序进行确认测试： (1) 确认测试顺序：先对修改部分进行测试，然后隔离修改部分，测试程序的未修改部分，最后再把它们集成起来进行测试。这种测试称为回归测试。 (2) 准备标准的测试用例。 (3) 充分利用软件工具帮助重新验证过程。

(4) 在重新确认过程中，需邀请用户参加。 维护后的验收──在交付新软件之前，维护主管部门要检验： (1) 全部文档是否完备，并已更新； (2) 所有测试用例和测试结果已经正确记载； (3) 记录软件配置所有副本的工作已经完成； (4) 维护工序和责任已经确定。

从维护角度来看所需测试种类 (1) 对修改事务的测试； (2) 对修改程序的测试； (3) 操作过程的测试； (4) 应用系统运用过程的测试； (5) 系统各部分之间接口的测试； (6) 作业控制语言的测试； (7) 与系统软件接口的测试；

(8) 软件系统之间接口的测试； (9) 安全性测试； (10) 后备／恢复过程的测试。

8.4 软件的可维护性 许多软件的维护十分困难，原因在于这些软件的文档不全、质量差、开发过程不注意采用好的方法，忽视程序设计风格等。 许多维护要求并不是因为程序中出错而提出的，而是为适应环境变化或需求变化而提出的。 为了使得软件能够易于维护，必须考虑使软件具有可维护性。 软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。

1. 可理解性 2. 可测试性 8.4.1 决定软件可维护性的因素 表现为外来读者理解软件的结构、功能、接口和内部处理过程的难易程度。 8.4.1 决定软件可维护性的因素 1. 可理解性 表现为外来读者理解软件的结构、功能、接口和内部处理过程的难易程度。 模块化（模块结构良好，高内聚，松耦合）、详细的设计文档、结构化设计、程序内部的文档和良好的高级程序设计语言等等，都对提高软件的可理解性有重要贡献。 2. 可测试性 诊断和测试的容易程度取决于软件容易理解的程度。软件结构、可用的测试工具和调试工具，以及以前设计的测试过程也都是非常重要的 1. 可理解性 软件可理解性 诊断和测试的容易程度取决于软件容易理解的程度。良好的文档对诊断和测试是至关重要的，此外，软件结构、可用的测试工具和调试工具，以及以前设计的测试过程也都是非常重要的。维护人员应该能够得到在开发阶段用过的测试方案，以便进行回归测试。在设计阶段应该尽力把软件设计成容易测试和容易诊断的。 对于程序模块来说，可以用程序复杂度来度量它的可测试性。模块的环形复杂度越大，可执行的路径就越多，因此，全面测试它的难度就越高。 3. 可修改性 软件容易修改的程度和本书第5章讲过的设计原理和启发规则直接有关。耦合、内聚、信息隐藏、局部化、控制域与作用域的关系等等，都影响软件的可修改性。 4. 可移植性 软件可移植性指的是，把程序从一种计算环境（硬件配置和操作系统）转移到另一种计算环境的难易程度。把与硬件、操作系统以及其他外部设备有关的程序代码集中放到特定的程序模块中，可以把因环境变化而必须修改的程序局限在少数程序模块中，从而降低修改的难度。 5. 可重用性 所谓重用（reuse）是指同一事物不做修改或稍加改动就在不同环境中多次重复使用。大量使用可重用的软件构件来开发软件，可以从下述两个方面提高软件的可维护性： (1) 通常，可重用的软件构件在开发时经过很严格的测试，可靠性比较高，且在每次重用过程中都会发现并清除一些错误，随着时间推移，这样的构件将变成实质上无错误的。因此，软件中使用的可重用构件越多，软件的可靠性越高，改正性维护需求越少。 （2） 很容易修改可重用的软件构件使之再次应用在新环境中，因此，软件中使用的可重用构件越多，适应性和完善性维护也就越容易。

3. 可修改性(和第五章设计原理和启发规则直接有关) 8.4.1 决定软件可维护性的因素 3. 可修改性(和第五章设计原理和启发规则直接有关) 4. 可移植性 把程序从一种计算机环境(硬件配置和操作系统)转移到 另一种计算环境的难易程度. 5. 可重用性 指同一事物不做修改或稍加改动就在不同的环境中多次 重复使用. 1. 可理解性 软件可理解性 诊断和测试的容易程度取决于软件容易理解的程度。良好的文档对诊断和测试是至关重要的，此外，软件结构、可用的测试工具和调试工具，以及以前设计的测试过程也都是非常重要的。维护人员应该能够得到在开发阶段用过的测试方案，以便进行回归测试。在设计阶段应该尽力把软件设计成容易测试和容易诊断的。 对于程序模块来说，可以用程序复杂度来度量它的可测试性。模块的环形复杂度越大，可执行的路径就越多，因此，全面测试它的难度就越高。 3. 可修改性 软件容易修改的程度和本书第5章讲过的设计原理和启发规则直接有关。耦合、内聚、信息隐藏、局部化、控制域与作用域的关系等等，都影响软件的可修改性。 4. 可移植性 软件可移植性指的是，把程序从一种计算环境（硬件配置和操作系统）转移到另一种计算环境的难易程度。把与硬件、操作系统以及其他外部设备有关的程序代码集中放到特定的程序模块中，可以把因环境变化而必须修改的程序局限在少数程序模块中，从而降低修改的难度。 5. 可重用性 所谓重用（reuse）是指同一事物不做修改或稍加改动就在不同环境中多次重复使用。大量使用可重用的软件构件来开发软件，可以从下述两个方面提高软件的可维护性： (1) 通常，可重用的软件构件在开发时经过很严格的测试，可靠性比较高，且在每次重用过程中都会发现并清除一些错误，随着时间推移，这样的构件将变成实质上无错误的。因此，软件中使用的可重用构件越多，软件的可靠性越高，改正性维护需求越少。 （2） 很容易修改可重用的软件构件使之再次应用在新环境中，因此，软件中使用的可重用构件越多，适应性和完善性维护也就越容易。

8.4.2 文 档 文档是影响软件可维护性的决定因素。往往文档比程序代码更重要。 软件系统的文档可以分为用户文档和系统文档两类。 ---- 用户文档主要描述系统功能和使用 方法，并不关心这些功能是怎样实现的； ---- 系统文档描述系统设计、实现和测试等各方面的内容。

软件文档应该满足下述要求： (1) 必须描述如何使用这个系统，没有这种描述时即使是最简单的系统也无法使用； (2) 必须描述怎样安装和管理这个系统； (3) 必须描述系统需求和设计； (4) 必须描述系统的实现和测试，以便使系统成为可维护的。

用户文档是用户了解系统的第一步，它应该能使用户获得对系统的准确的初步印象。文档的结构方式应该使用户能够方便地根据需要阅读有关的内容。 1. 用户文档 用户文档是用户了解系统的第一步，它应该能使用户获得对系统的准确的初步印象。文档的结构方式应该使用户能够方便地根据需要阅读有关的内容。 用户文档至少应该包括下述5方面的内容： (1) 功能描述； (2) 安装文档； (3) 使用手册； (4) 参考手册； (5) 操作员指南(如果需要有系统操作员的话) 。 上述内容可以分别作为独立的文档， 也可以作为一个文档的不同分册， 具体做法应该由系统规模决定。 1. 用户文档 用户文档是用户了解系统的第一步，它应该能使用户获得对系统的准确的初步印象。文档的结构方式应该使用户能够方便地根据需要阅读有关的内容。 用户文档至少应该包括下述5方面的内容： (1) 功能描述，说明系统能做什么； (2) 安装文档，说明怎样安装这个系统以及怎样使系统适应特定的硬件配置； (3) 使用手册，简要说明如何着手使用这个系统(应该通过丰富例子说明怎样使用常用的系统功能，还应该说明用户操作错误时怎样恢复和重新启动)； (4) 参考手册，详尽描述用户可以使用的所有系统设施以及它们的使用方法，还应该解释系统可能产生的各种出错信息的含义(对参考手册最主要的要求是完整，因此通常使用形式化的描述技术)； (5) 操作员指南(如果需要有系统操作员的话)，说明操作员应该如何处理使用中出现的各种情况。 上述内容可以分别作为独立的文档，也可以作为一个文档的不同分册，具体做法应该由系统规模决定。

2. 系统文档 ---- 所谓系统文档指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。 ---- 描述系统设计、实现和测试的文档对于理解程序和维护程序来说是极端重要的。 ---- 和用户文档类似，系统文档的结构也应该能把读者从对系统概貌的了解，引导到对系统每个方面每个特点的更形式化更具体的认识。

建立明确的软件质量目标和优先级 使用提高软件质量的技术和工具 进行明确的质量保证审查 选择可维护的程序设计语言 改进程序的文档 8.4.3 提高可维护性的方法 建立明确的软件质量目标和优先级 使用提高软件质量的技术和工具 进行明确的质量保证审查 选择可维护的程序设计语言 改进程序的文档

8.4.4 可维护性复审 在软件工程过程的每一个阶段都应该考虑并努力提高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。

在完成了每项维护工作之后，都应该对软件维护本身进行仔细认真的复审。 --- 维护应该针对整个软件配置，不应该只修改源程序代码。当对源程序代码的修改没有反映在设计文档或用户手册中时，就会产生严重的后果。 --- 每当对数据、软件结构、模块过程或任何其他有关的软件特点做了改动时，必须立即修改相应的技术文档。不能准确反映软件当前状态的设计文档可能比完全没有文档更坏。 --- 用户通常根据描述软件特点和使用方法的用户文档来使用、评价软件。如果对软件的可执行部分的修改没有及时反映在用户文档中，则必然会使用户因为受挫折而产生不满。

8.5 预防性维护 预防性维护方法是由Miller提出来的，他把这种方法定义为：“把今天的方法学应用到昨天的系统上，以支持明天的需求。” 开发和维护者不应等待用户的维护申请,在条件具备时应该主动地进行预防性维护。 预防性维护对象: 预计若干年内将继续使用的程序 当今正成功使用的程序 最近的将来要进行大修改和完善的程序

8.6 软件再工程过程（Software Reengineering） 再工程是一个重构活动（类比 重建一所房子） 开始重建前，首先检查一下房子。确定它是否确实需要重建？ 在拆掉并重建房子前，确定其结构是否牢固。若结构良好，则可能是“改造”。 在开始重建前，确保你已经了解房子最初是如何建造的。（墙内部，了解布线、管道以及内部结构。） 如果开始重建，应该使用最现代的，耐久的材料。 如果决定重建，一定要采用严格的方式，使用现在及将来都将获得高质量的做法。

8.6 软件再工程过程 （Software Reengineering） 软件再工程是一类软件工程活动，是一个工程过程, 它将逆向工程、重构和正向工程组合起来,将现存系统重新构造为新的形式。 软件再工程过程模型

软件再工程过程示意图 新需求 需求 （重构） 正 向 工 程 逆 向 工 程 （重构） 设计 设计 （重构） 代码 代码

1. 库存目录分析 2. 文档重构 3. 逆向工程 4. 代码重构 5. 数据重构 6. 正向工程 软件再工程过程模型所定义的6类活动 1. 库存目录分析 2. 文档重构 3. 逆向工程 4. 代码重构 5. 数据重构 6. 正向工程 1. 库存目录分析 每个软件组织都应该保存其拥有的所有应用系统的库存目录。该目录包含关于每个应用系统的基本信息（例如，应用系统的名字，最初构建它的日期，已做过的实质性修改次数，过去18个月报告的错误，用户数量，安装它的机器数量，它的复杂程度，文档质量，整体可维护性等级，预期寿命，在未来36个月内的预期修改次数，业务重要程度等）。 应该仔细分析库存目录，按照业务重要程度、寿命、当前可维护性、预期的修改次数等标准，把库中的应用系统排序，从中选出再工程的候选者，然后明智地分配再工程所需要的资源。

本章小结 软件维护的4类活动 （改正性、适应性、完善性、预防性） 决定软件可维护性的基本要素 （可理解、可测试、可修改、可移植和可重用性） 文档是影响软件可维护性的决定因素 软件再工程（预防性维护）