第13章软件维护

1、 第十三章第十三章 软件维护软件维护软件工程软件工程( (第三版第三版) ) 齐治昌齐治昌 谭庆平谭庆平 宁洪宁洪第十三章第十三章 软件维护软件维护13.1 13.1 软件维护与进化的概念软件维护与进化的概念13.2 13.2 软件维护的过程模型软件维护的过程模型13.3 13.3 可维护性可维护性13.4 13.4 维护活动及实施策略维护活动及实施策略13.5 13.5 维护的副作用维护的副作用13.6 13.6 逆向工程与软件重构逆向工程与软件重构2021-12-22国防科技大学计算机学院2软件维护软件维护我们讨论了构建一个软件系统的全过程，但系我们讨论了构建一个软件系统的全过程，但系统的

2、交付并不意味着其生存周期的结束。统的交付并不意味着其生存周期的结束。系统构建之后通常还会不断地变化，我们面临系统构建之后通常还会不断地变化，我们面临的挑战是如何维护一个持续演化的系统。的挑战是如何维护一个持续演化的系统。演化可能是由于需求和环境发生变化，也可能演化可能是由于需求和环境发生变化，也可能是软件自身暴露出问题。统计和估测结果表明，是软件自身暴露出问题。统计和估测结果表明，信息系统中硬件费用一般占信息系统中硬件费用一般占35%35%，软件费用占，软件费用占65%65%，而软件后期维护费用有时竟高达软件总，而软件后期维护费用有时竟高达软件总费用的费用的80%80%，所有前期开发费用仅占，

3、所有前期开发费用仅占20%20%。许多大型软件公司为维护已有软件耗费大量人许多大型软件公司为维护已有软件耗费大量人力、财力。力、财力。必须建立一套评估、控制和实施软件维护的机必须建立一套评估、控制和实施软件维护的机制制, ,这就是本章重点讨论的内容。这就是本章重点讨论的内容。2021-12-22国防科技大学计算机学院313.1 13.1 软件维护与进化的概念软件维护与进化的概念软件维护是软件交付后，保障软件生产活动，发软件维护是软件交付后，保障软件生产活动，发挥软件社会和经济效益的关键。挥软件社会和经济效益的关键。软件交付并投入运行后，任何针对系统变更所做软件交付并投入运行后，任何针对系统变更

4、所做的工作，都是维护的工作，都是维护(maintenance)(maintenance)。软件维护究其原因可分为：纠错性维护、适应性软件维护究其原因可分为：纠错性维护、适应性维护、完善性维护和预防性维护四类。维护、完善性维护和预防性维护四类。纠错性维护是为诊断和改正软件系统中潜藏的缺纠错性维护是为诊断和改正软件系统中潜藏的缺陷而进行的活动。陷而进行的活动。测试不可能排除大型软件系统中所有的缺陷测试不可能排除大型软件系统中所有的缺陷, ,软件软件交付后交付后, ,用户在使用软件的过程中会发现软件潜伏用户在使用软件的过程中会发现软件潜伏的缺陷的缺陷, ,他们会向开发人员报告并要求维护。他们会向开发

5、人员报告并要求维护。2021-12-22国防科技大学计算机学院4软件维护与进化的概念软件维护与进化的概念维护人员找出软件失效的原因，进行改正，并根据维护人员找出软件失效的原因，进行改正，并根据需要对需求、设计、代码、测试序列以及文档做出需要对需求、设计、代码、测试序列以及文档做出相应变更。相应变更。最初的修改可能是临时性的，即为保持系统运行所最初的修改可能是临时性的，即为保持系统运行所采取的一些应急措施。采取的一些应急措施。事后应对维护方案仔细推敲，在软件工具的支持下事后应对维护方案仔细推敲，在软件工具的支持下进行回归测试，自动修改相应的文档。进行回归测试，自动修改相应的文档。适应性维护是为适

6、应软件运行环境变化，如操作系适应性维护是为适应软件运行环境变化，如操作系统变更、硬件更新，而修改软件的活动。统变更、硬件更新，而修改软件的活动。应用软件的使用寿命很长，多数超过十年应用软件的使用寿命很长，多数超过十年, ,但运行但运行环境更新通常不会超过十年环境更新通常不会超过十年,CPU,CPU基本是一年半一代基本是一年半一代, ,操作系统不断地推出新版本操作系统不断地推出新版本, ,外部设备和其他系统外部设备和其他系统元素也频繁升级和变化元素也频繁升级和变化, ,因此适应性维护是十分必因此适应性维护是十分必要的。要的。2021-12-22国防科技大学计算机学院5软件维护与进化的概念软件维护

7、与进化的概念完善性维护是根据用户在软件使用过程中提出的一完善性维护是根据用户在软件使用过程中提出的一些新需求实施的维护活动。些新需求实施的维护活动。应用软件运行期间应用软件运行期间, ,用户可能请求增加新功能、建用户可能请求增加新功能、建议修改已有功能或提出某些改进意见。议修改已有功能或提出某些改进意见。完善性维护通常占所有软件维护工作量的一半以上。完善性维护通常占所有软件维护工作量的一半以上。预防性维护是优化软件系统结构和可理解性，改善预防性维护是优化软件系统结构和可理解性，改善可维护性和可靠性。可维护性和可靠性。软件长期维护会使体系结构变坏，难以理解，增加软件长期维护会使体系结构变坏，难以

8、理解，增加维护费用，降低运行效率。维护费用，降低运行效率。这类维护活动涉及逆向工程这类维护活动涉及逆向工程(reverse engineering)(reverse engineering)和软件重构。留待和软件重构。留待13.613.6节专门讨论。节专门讨论。2021-12-22国防科技大学计算机学院6软件维护与进化的概念软件维护与进化的概念调查表明：约有调查表明：约有65%65%的维护属完善性维护；的维护属完善性维护；18%18%的的维护属适应性维护；维护属适应性维护；17%17%的维护属纠错性维护。的维护属纠错性维护。修补系统缺陷并不是费用最高的维护活动，适应修补系统缺陷并不是费用最高的

9、维护活动，适应新环境的系统进化和实现新需求以及需求变更占新环境的系统进化和实现新需求以及需求变更占用了绝大部分的维护工作量。用了绝大部分的维护工作量。实践中，几类维护之间没有明确界限。实践中，几类维护之间没有明确界限。如，在使软件适应新环境的同时，还可能增加新如，在使软件适应新环境的同时，还可能增加新功能，充分利用该环境提供的服务；功能，充分利用该环境提供的服务；某个软件失误可能是因为系统用事先未预料到的某个软件失误可能是因为系统用事先未预料到的方式工作，修正这类失误的另一种方法是改变系方式工作，修正这类失误的另一种方法是改变系统的这种工作方式，等等。统的这种工作方式，等等。2021-12-2

10、2国防科技大学计算机学院7软件维护与进化的概念软件维护与进化的概念在前几章讨论系统开发时，主要关注如何生产能在前几章讨论系统开发时，主要关注如何生产能够实现需求并能正确运行的代码。够实现需求并能正确运行的代码。维护不仅要理解软件制品，而且要了解用户对系维护不仅要理解软件制品，而且要了解用户对系统运行的意见，预测可能出现的问题，考虑业务统运行的意见，预测可能出现的问题，考虑业务需求变化带来的软件功能的新变更，以及硬件、需求变化带来的软件功能的新变更，以及硬件、软件或接口变更带来的系统变化。软件或接口变更带来的系统变化。维护涉及的范围更广，内容更多维护涉及的范围更广，内容更多。2021-12-22

11、国防科技大学计算机学院813.2 13.2 软件维护的过程模型软件维护的过程模型实践证明，有重要应用价值的软件实践证明，有重要应用价值的软件，生存周期一生存周期一般很长，软件维护不可避免。般很长，软件维护不可避免。从软件开发的螺旋模型看从软件开发的螺旋模型看, ,软件维护是软件开发的软件维护是软件开发的继续继续, ,是软件的进化。是软件的进化。多数维护团队已不再是该软件的开发团队，软件多数维护团队已不再是该软件的开发团队，软件维护面临许多困难。维护面临许多困难。本节主要讨论软件维护的主要内容、软件工程的本节主要讨论软件维护的主要内容、软件工程的目标原则对这些活动的影响、软件维护的成本、目标原则

12、对这些活动的影响、软件维护的成本、软件维护存在的问题等。软件维护存在的问题等。2021-12-22国防科技大学计算机学院913.2.1 13.2.1 结构化与非结构化的维护结构化与非结构化的维护一个维护需求（申请）被接收后一个维护需求（申请）被接收后, ,可能发生的事件可能发生的事件如图如图13.113.1所示。如果软件配置中唯一可用的是源代所示。如果软件配置中唯一可用的是源代码码, ,那么维护只能从那么维护只能从“苦读苦读”代码开始。代码开始。由于缺乏内部文档由于缺乏内部文档, ,读代码是一项很枯燥、很困难读代码是一项很枯燥、很困难的工作。的工作。软件系统的许多微妙之处软件系统的许多微妙之处

13、( (例如软件总体结构、全例如软件总体结构、全局数据、系统接口、性能和设计方面的约束等局数据、系统接口、性能和设计方面的约束等) )不不是搞不清楚就是常常被误解是搞不清楚就是常常被误解, ,以致无法估量对源代以致无法估量对源代码修改所产生的后果。特别是，由于没有保存测试码修改所产生的后果。特别是，由于没有保存测试记录记录, ,使使“回归测试回归测试”无法进行。无法进行。对于没有使用良好开发方法开发的软件对于没有使用良好开发方法开发的软件, ,不得不采不得不采用非结构化的方式进行维护并为此付出高昂的代价用非结构化的方式进行维护并为此付出高昂的代价( (浪费大量人力浪费大量人力, ,让维护人员有挫

14、折感让维护人员有挫折感) )。2021-12-22国防科技大学计算机学院102021-12-22国防科技大学计算机学院11图13.1 非结构化与结构化维护结构化与非结构化的维护结构化与非结构化的维护如果欲维护的软件存在一个完整的软件配置如果欲维护的软件存在一个完整的软件配置, ,维护活动将从阅读设计文档开始。首先确定软维护活动将从阅读设计文档开始。首先确定软件的重要结构、性能及接口特征件的重要结构、性能及接口特征, ,评估这次维评估这次维护可能带来的影响并规划出一个具体实施方案护可能带来的影响并规划出一个具体实施方案; ;然后从修改设计入手然后从修改设计入手( (采用以前讨论过的设计采用以前讨

15、论过的设计技术技术) )，设计复审通过之后再修改代码，设计复审通过之后再修改代码, ,并参照并参照测试规格说明书对软件进行回归测试测试规格说明书对软件进行回归测试, ,测试通测试通过后交付用户使用。过后交付用户使用。上述过程也称为结构化维护上述过程也称为结构化维护, ,它是采用软件工它是采用软件工程方法学开发软件的自然结果。拥有完整的软程方法学开发软件的自然结果。拥有完整的软件配置能减少维护工作量，提高维护质量。件配置能减少维护工作量，提高维护质量。2021-12-22国防科技大学计算机学院1213.2.2 13.2.2 维护的成本维护的成本过去的四十年过去的四十年, ,软件维护的成本在不断增

16、长。软件维护的成本在不断增长。2020世纪世纪7070年代年代, ,一个信息系统机构用于软件维一个信息系统机构用于软件维护的费用占其软件总预算的护的费用占其软件总预算的353540%40%8080年代接近年代接近60%60%若维护方式没有大的改进若维护方式没有大的改进, ,未来未来几年，许多大型软件公司可能要将其预算的几年，许多大型软件公司可能要将其预算的80%80%用于软件系统的维护上。用于软件系统的维护上。除软件维护耗费的财力外除软件维护耗费的财力外, ,其他因素也引起人其他因素也引起人们的注意。们的注意。如如, ,由于资源由于资源( (人力、设备人力、设备) )优先用于维护任务优先用于维

17、护任务, ,影响新软件系统的开发，要付出无形的代价。影响新软件系统的开发，要付出无形的代价。2021-12-22国防科技大学计算机学院13维护的成本维护的成本某些貌似合理但实际不能满足的维护请求将引某些貌似合理但实际不能满足的维护请求将引起用户不满起用户不满; ;在软件维护过程中引入的潜在缺陷降低了软件在软件维护过程中引入的潜在缺陷降低了软件的质量的质量; ;从开发小组中临时抽调工程师从事维护工作冲从开发小组中临时抽调工程师从事维护工作冲击正在进行的开发等等。击正在进行的开发等等。维护旧程序使生产率维护旧程序使生产率( (按每人月代码行或每人按每人月代码行或每人月功能点计算月功能点计算) )大

18、幅度下降。大幅度下降。据报道据报道, ,生产率最多可能降低四十倍生产率最多可能降低四十倍, ,即每行用即每行用2525元开发的软件，维护一行可能耗费元开发的软件，维护一行可能耗费10001000元。元。在设计和实现时为提高可维护性投资是值得的。在设计和实现时为提高可维护性投资是值得的。2021-12-22国防科技大学计算机学院14维护的成本维护的成本维护成本与开发成本的比例在不同应用领域中是维护成本与开发成本的比例在不同应用领域中是不同的。不同的。对于业务应用系统，维护费用与系统开发成本大对于业务应用系统，维护费用与系统开发成本大体相等。体相等。对于嵌入式实时系统，维护费用能达到开发成本对于嵌

19、入式实时系统，维护费用能达到开发成本的四倍以上，这类系统的高可靠性和高性能需求的四倍以上，这类系统的高可靠性和高性能需求需要模块间紧密连接，因此变更起来特别困难。需要模块间紧密连接，因此变更起来特别困难。软件维护工作量分为生产性软件维护工作量分为生产性( (用于分析与评价，修用于分析与评价，修改设计和代码等改设计和代码等) )和助动性和助动性( (用于理解代码功能，用于理解代码功能，解释数据结构、接口特征与性能约束等解释数据结构、接口特征与性能约束等) )两类。两类。2021-12-22国防科技大学计算机学院15维护的成本维护的成本下面给出维护工作量的一种估算模型下面给出维护工作量的一种估算模

20、型: : M=P+K M=P+K* *e e(c-d)(c-d) （13-113-1）其中其中M M表示维护工作量，表示维护工作量，P P表示生产性工作量，表示生产性工作量，K K为经为经验常数验常数c c表示复杂度表示复杂度, ,标志设计的好坏及文档完整程度标志设计的好坏及文档完整程度d d表示对维护软件的熟悉程度表示对维护软件的熟悉程度模型表明模型表明, ,倘若未用好的软件开发方法倘若未用好的软件开发方法( (即未遵即未遵循软件工程的思想循软件工程的思想) )或软件开发人员不能参与或软件开发人员不能参与维护维护, ,则维护工作量则维护工作量( (和成本和成本) )将成指数增长。将成指数增长

21、。2021-12-22国防科技大学计算机学院1613.2.3 13.2.3 可能存在的问题可能存在的问题软件维护中出现的大部分问题都可归咎于软件规划软件维护中出现的大部分问题都可归咎于软件规划和开发方法的缺陷。和开发方法的缺陷。软件开发若不严格遵循软件开发标准软件开发若不严格遵循软件开发标准, ,软件维护就软件维护就会遇到许多困难。会遇到许多困难。影响影响维护的问题维护的问题: :(1)(1)很难甚至不可能追踪软件版本的进化过程很难甚至不可能追踪软件版本的进化过程, ,软件的软件的变化没在相应文档中反映出来变化没在相应文档中反映出来; ;(2)(2)很难甚至不可能追踪软件的整个创建过程；很难甚

22、至不可能追踪软件的整个创建过程；(3)(3)理解他人的程序非常困难理解他人的程序非常困难, ,当软件配置不全当软件配置不全, ,仅有仅有源代码时问题尤为严重源代码时问题尤为严重; ;(4)(4)软件人员流动性很大软件人员流动性很大, ,维护他人软件时很难得到开维护他人软件时很难得到开发者的帮助；发者的帮助；2021-12-22国防科技大学计算机学院17可能存在的问题可能存在的问题(5)(5)软件没有文档、或文档不全、或文档不易理解、软件没有文档、或文档不全、或文档不易理解、或与源代码不一致；或与源代码不一致；(6)(6)多数软件设计未考虑修改的需要多数软件设计未考虑修改的需要( (有些设计方法

23、有些设计方法采用了功能独立和对象类型等一些便于修改的概采用了功能独立和对象类型等一些便于修改的概念念),),软件修改不仅困难而且容易出错。软件修改不仅困难而且容易出错。(7)(7)软件维护不是一项有吸引力的工作软件维护不是一项有吸引力的工作, ,从事这项工从事这项工作令人缺乏成就感。作令人缺乏成就感。许多遗留系统未采用软件工程的思想和方法开发许多遗留系统未采用软件工程的思想和方法开发( (大都运行了十年以上大都运行了十年以上),),问题尤其严重。问题尤其严重。下面从技术和管理的角度讨论解决这些问题的具下面从技术和管理的角度讨论解决这些问题的具体措施。体措施。2021-12-22国防科技大学计算

24、机学院1813.3 13.3 可维护性可维护性软件可维护性指软件可维护性指, ,理解、改正、调整和改进软件的理解、改正、调整和改进软件的难易程度。难易程度。可维护性是软件质量的重要属性，涉及软件开发可维护性是软件质量的重要属性，涉及软件开发方法、工具、过程、软件制品、文档、软件管理、方法、工具、过程、软件制品、文档、软件管理、资金投入、维护计划、维护团队等。资金投入、维护计划、维护团队等。可维护性是指导软件工程活动的一条基本原则，可维护性是指导软件工程活动的一条基本原则，也是软件工程追求的一个目标。也是软件工程追求的一个目标。2021-12-22国防科技大学计算机学院1913.3.113.3.

25、1影响可维护性的因素影响可维护性的因素影响软件可维护性影响软件可维护性的的因素因素： 设计、编码和测试不规范设计、编码和测试不规范，软件配置不全软件配置不全开发环境的因素开发环境的因素: : 训练有素的软件团队；训练有素的软件团队； 维护团队是否熟悉经过多次维护的系统；维护团队是否熟悉经过多次维护的系统； 软件的可理解性，包括：软件结构、描述软件制品的语软件的可理解性，包括：软件结构、描述软件制品的语言（如言（如UML,UML,程序设计语言等）、文档及标准化程度等；程序设计语言等）、文档及标准化程度等； 操作系统的标准化程度；操作系统的标准化程度； 维护工具和环境；维护工具和环境； 生成测试用

26、例的能力；生成测试用例的能力； 对于嵌入式软件系统维护应有专门的调试工具对于嵌入式软件系统维护应有专门的调试工具2021-12-22国防科技大学计算机学院2013.3.2 13.3.2 若干量化的测度若干量化的测度软件可维护性与软件质量和可靠性一样是难以量软件可维护性与软件质量和可靠性一样是难以量化的概念化的概念, ,然而借助维护活动中可以定量估算的属然而借助维护活动中可以定量估算的属性性, ,能间接地度量可维护性。能间接地度量可维护性。面向时间的度量包括：面向时间的度量包括： 发现问题耗费的时间发现问题耗费的时间; ; 收集维护工具耗费的时间收集维护工具耗费的时间; ; 分析问题耗费的时间分

27、析问题耗费的时间; ; 形成修改说明书耗费的时间；形成修改说明书耗费的时间； 纠错纠错( (或修改或修改) ) 耗费的时间耗费的时间; ;2021-12-22国防科技大学计算机学院21若干量化的测度若干量化的测度 局部、整体测试耗费的时间局部、整体测试耗费的时间; ; 维护复审耗费的时间维护复审耗费的时间; ; 系统恢复耗费的时间。系统恢复耗费的时间。收集上述度量数据作为管理者评估人员、工具、收集上述度量数据作为管理者评估人员、工具、技术有效性的依据技术有效性的依据, ,除了这些面向时间的度量外除了这些面向时间的度量外, ,有关设计结构和软件复杂性的度量亦可间接说明有关设计结构和软件复杂性的度

28、量亦可间接说明软件的可维护性。软件的可维护性。2021-12-22国防科技大学计算机学院2213.3.313.3.3保证可维护性的复审保证可维护性的复审可维护性是软件质量标准的基本要素。可维护性是软件质量标准的基本要素。软件制品的复审活动经常遇到可维护性的内容。软件制品的复审活动经常遇到可维护性的内容。在需求分析制品的复审中在需求分析制品的复审中, ,应对将来可能修改应对将来可能修改和可以改进的部分进行注释和可以改进的部分进行注释, ,注意为软件移植注意为软件移植提供方便，并考虑可能影响软件维护的系统界提供方便，并考虑可能影响软件维护的系统界面面; ;在设计阶段的复审中在设计阶段的复审中, ,

29、应从易于维护和提高设应从易于维护和提高设计总体质量的角度全面评审数据设计、总体结计总体质量的角度全面评审数据设计、总体结构设计、过程设计和界面设计构设计、过程设计和界面设计; ;代码复审主要强调编程风格和内部文档，他们代码复审主要强调编程风格和内部文档，他们是影响可维护性的重要因素是影响可维护性的重要因素; ;2021-12-22国防科技大学计算机学院23保证可维护性的复审保证可维护性的复审最后最后, ,在软件正式交付之前在软件正式交付之前, ,应该进行一次预防性应该进行一次预防性维护，使代码具有良好的结构，并保持文档和代维护，使代码具有良好的结构，并保持文档和代码的一致性。码的一致性。软件维

30、护活动完成时，要进行复审软件维护活动完成时，要进行复审, ,所用方法下一所用方法下一节讨论。正式的可维护性复审放在测试完成之后节讨论。正式的可维护性复审放在测试完成之后, ,称为配置复审。称为配置复审。目的是保证配置中所有成份的完整、协调、易于目的是保证配置中所有成份的完整、协调、易于理解且便于修改控制。软件配置管理在十六章讨理解且便于修改控制。软件配置管理在十六章讨论。论。2021-12-22国防科技大学计算机学院2413.4 13.4 维护活动及实施策略维护活动及实施策略软件维护工作在维护申请提出之前就开始了软件维护工作在维护申请提出之前就开始了，包包括括：建立维护组织建立维护组织, ,强

31、制报告和评估的过程强制报告和评估的过程; ;为每个维护申请确定标准化的事件序列为每个维护申请确定标准化的事件序列; ;制定保存维护活动记录的制度和有关复审及评制定保存维护活动记录的制度和有关复审及评估的标准。估的标准。2021-12-22国防科技大学计算机学院2513.4.113.4.1维护组织维护组织软件维护阶段相对来说是漫长且不定期的软件维护阶段相对来说是漫长且不定期的, ,长期以来很少建立正式的维护组织长期以来很少建立正式的维护组织, ,而多采而多采用用“抓着谁算谁抓着谁算谁”的办法组织维护力量。的办法组织维护力量。目前人们普遍认识到目前人们普遍认识到, ,即使对于一个小的软即使对于一个

32、小的软件开发队伍而言件开发队伍而言, ,非正式地定岗定责也绝对非正式地定岗定责也绝对必要。必要。图图13.213.2给出了一种组织模式。给出了一种组织模式。2021-12-22国防科技大学计算机学院26图图13.2 13.2 维护的一种组织模式维护的一种组织模式2021-12-22国防科技大学计算机学院27维护组织维护组织每个维护申请通过维护管理员转告给系统管理每个维护申请通过维护管理员转告给系统管理员员, ,系统管理员一般都是对程序系统管理员一般都是对程序( (某一部分某一部分) )特特别熟悉的技术人员别熟悉的技术人员, ,他们对维护申请及可能引他们对维护申请及可能引起的软件修改进行评估起的

33、软件修改进行评估, ,并向修改控制决策机并向修改控制决策机构构( (一个或一组管理者一个或一组管理者) )报告报告, ,由它最后确定是由它最后确定是否采取行动。否采取行动。依照这样的组织方式开展维护活动能减少混乱依照这样的组织方式开展维护活动能减少混乱和盲目性和盲目性, ,避免因小失大的情况发生。避免因小失大的情况发生。上述各个岗位都不需要专职人员上述各个岗位都不需要专职人员, ,但必须为胜但必须为胜任者任者, ,并且要早在维护活动开始之前就明确各并且要早在维护活动开始之前就明确各自责任自责任, ,避免互相推诿避免互相推诿, ,急功近利的现象。急功近利的现象。2021-12-22国防科技大学计

34、算机学院2813.4.213.4.2维护的报告与评估维护的报告与评估所有的软件维护申请都应该采用标准的格式所有的软件维护申请都应该采用标准的格式, ,软件软件开发人员统一发放的维护申请单开发人员统一发放的维护申请单(Maintenance (Maintenance Request Form)Request Form)或称为软件问题报告单或称为软件问题报告单(Software (Software Problem Report),Problem Report),由用户根据需要填写。由用户根据需要填写。如果用户确实发现了缺陷如果用户确实发现了缺陷, ,必须完整地记录出错现必须完整地记录出错现场信息场

35、信息( (包括输入数据、列表文件和其他有关信包括输入数据、列表文件和其他有关信息息) )；如果用户提出适应性或完善性维护请求如果用户提出适应性或完善性维护请求, ,需同时提需同时提交一个简短的修改规约交一个简短的修改规约( (即简单的需求规约即简单的需求规约) )。2021-12-22国防科技大学计算机学院29维护的报告与评估维护的报告与评估维护管理员将维护管理员将MRFMRF提交给系统管理员评估。提交给系统管理员评估。一个维护申请被核准后一个维护申请被核准后,MRF,MRF文档成为规划本次维文档成为规划本次维护任务的依据护任务的依据, ,软件组织要另外制定一个软件修改软件组织要另外制定一个软

36、件修改报告单报告单(Software Change Report)(Software Change Report)，说明实现，说明实现MRFMRF所需工作量、维护活动的性质、本次维护请求所需工作量、维护活动的性质、本次维护请求优先级、本次修改的背景数据。优先级、本次修改的背景数据。将将SCRSCR提交给修改控制决策机构提交给修改控制决策机构, ,供进一步规划维供进一步规划维护活动使用。护活动使用。2021-12-22国防科技大学计算机学院3013.4.3 13.4.3 维护工作流维护工作流当提出一个维护申请之后当提出一个维护申请之后, ,发生的工作流程如图发生的工作流程如图13.313.3所示

37、。所示。首先确定用户请求维护的类型首先确定用户请求维护的类型, ,有时用户认为是改有时用户认为是改错的请求错的请求, ,开发人员则可能认为是适应性或完善性开发人员则可能认为是适应性或完善性维护维护, ,如果出现这种分歧如果出现这种分歧, ,必须通过协商达到共识。必须通过协商达到共识。2021-12-22国防科技大学计算机学院312021-12-22国防科技大学计算机学院32图图13.3 维护工作流维护工作流维护工作流维护工作流对一项改错性维护申请对一项改错性维护申请( (图中标为图中标为“出错出错”通通路路),),首先要估计缺陷的严重程度首先要估计缺陷的严重程度, ,如果是一项如果是一项严重缺

38、陷严重缺陷( (例如例如, ,某关键部分不能工作某关键部分不能工作),),则应由则应由系统管理员系统管理员“调兵遣将调兵遣将”, ,立即开始分析问题立即开始分析问题; ;如果问题并不严重如果问题并不严重, ,这项维护申请应与其他任这项维护申请应与其他任务统筹考虑务统筹考虑, ,根据轻重缓急再行安排。根据轻重缓急再行安排。某些场合某些场合, ,维护活动不能按常规进行。维护活动不能按常规进行。如未对潜在的副作用进行估计或未修改文档就如未对潜在的副作用进行估计或未修改文档就急忙动手修改代码。急忙动手修改代码。“救火救火”式维护仅限于少数危难时刻式维护仅限于少数危难时刻, ,并且保并且保证只是延迟而不

39、是放弃对维护的控制和评估。证只是延迟而不是放弃对维护的控制和评估。一旦危机过去一旦危机过去, ,应立即补行所有的控制和评估应立即补行所有的控制和评估过程过程, ,防止由此产生的更大危机。防止由此产生的更大危机。2021-12-22国防科技大学计算机学院33维护工作流维护工作流适应性和完善性维护申请执行另一条处理路径适应性和完善性维护申请执行另一条处理路径首先对所申请的维护进行评估并根据优先级在维护首先对所申请的维护进行评估并根据优先级在维护请求队列中排队请求队列中排队根据根据企业本身的策略、可用的、软件当前及未来发企业本身的策略、可用的、软件当前及未来发展趋势等因素展趋势等因素决定决定完善性维

40、护完善性维护的的优先级。优先级。某项维护申请一旦核准并在队列中排列某项维护申请一旦核准并在队列中排列, ,便开始规便开始规划进度划进度, ,如同接受一项新的开发任务一样。如同接受一项新的开发任务一样。维护维护的的技术工作：修改软件设计，进行设计复审，技术工作：修改软件设计，进行设计复审，必要时重新编码；实施单元测试、综合测试必要时重新编码；实施单元测试、综合测试( (包括包括回归测试回归测试) )、确认测试和复查。、确认测试和复查。复查旨在确认软件配置中所有项目完整、协调，并复查旨在确认软件配置中所有项目完整、协调，并保证满足保证满足MRFMRF。软件维护可视为软件工程的一个递归过程。软件维护

41、可视为软件工程的一个递归过程。2021-12-22国防科技大学计算机学院34维护工作流维护工作流当一项软件维护任务完成后当一项软件维护任务完成后, ,进行一次状况复进行一次状况复审大有益处。状况复审主要考虑下列问题审大有益处。状况复审主要考虑下列问题: : 依照当前状态依照当前状态, ,在设计、编码和测试的哪些方在设计、编码和测试的哪些方面还能用其他方法进行面还能用其他方法进行? ? 哪些维护资源可用但未用；哪些维护资源可用但未用； 这次维护活动中主要这次维护活动中主要( (或次要或次要) )的障碍有哪些的障碍有哪些? ? 在维护请求中有预防性维护吗在维护请求中有预防性维护吗? ?状况复审的目

42、的在于促进未来的维护工作状况复审的目的在于促进未来的维护工作, ,同同时也为有效管理软件组织提供重要的反馈信息。时也为有效管理软件组织提供重要的反馈信息。2021-12-22国防科技大学计算机学院3513.4.4 13.4.4 保存维护记录保存维护记录长期以来长期以来, ,人们对于保存软件工程各个阶段的人们对于保存软件工程各个阶段的记录未给予足够的重视记录未给予足够的重视, ,因此软件维护的历史因此软件维护的历史记录缺乏记录缺乏, ,以致人们很难估计各种维护技术的以致人们很难估计各种维护技术的有效性有效性, ,不能确定一个商品化软件的质量不能确定一个商品化软件的质量, ,也不也不能估算维护的实

43、际成本。能估算维护的实际成本。维护过程需要记录的数据包括维护过程需要记录的数据包括: : 程序信息：程序标志、源程序行数、目标程程序信息：程序标志、源程序行数、目标程序指令条数、编程语言序指令条数、编程语言; ; 程序运行信息：安装程序的日期、自安装之程序运行信息：安装程序的日期、自安装之日起程序运行的次数、自安装之日起程序失败日起程序运行的次数、自安装之日起程序失败的次数的次数; ;2021-12-22国防科技大学计算机学院36保存维护记录保存维护记录 程序维护信息：程序修改处的层数和标志、程序维护信息：程序修改处的层数和标志、程序变动增加的源程序行数、程序变动删程序变动增加的源程序行数、程

44、序变动删除的源程序行数、每处改动耗费的人时数、除的源程序行数、每处改动耗费的人时数、程序改动日期；程序改动日期； 软件工程师标志软件工程师标志; ; 其它维护信息：其它维护信息：MRFMRF标志、维护的类型、标志、维护的类型、维护开始和结束日期、此次维护人时数、维护开始和结束日期、此次维护人时数、本次维护的纯利润，等等。本次维护的纯利润，等等。每次维护完成后应立即收集上述数据每次维护完成后应立即收集上述数据, ,并以并以此为基础构造维护数据库此为基础构造维护数据库, ,供维护评价用。供维护评价用。2021-12-22国防科技大学计算机学院3713.4.5 13.4.5 评价维护活动评价维护活动

45、如果缺乏真实可信的数据如果缺乏真实可信的数据, ,评估活动毫无意义。在保存评估活动毫无意义。在保存维护记录的前提下维护记录的前提下, ,可对维护性能进行度量可对维护性能进行度量, ,统计下列数统计下列数据是必要的据是必要的: : 程序每次运行的平均失效次数程序每次运行的平均失效次数; ; 各类维护耗费的总人时数各类维护耗费的总人时数; ; 各种程序、各种语言及各类维护的程序平均变各种程序、各种语言及各类维护的程序平均变 维护活动增删一个语句平均花费的人时数维护活动增删一个语句平均花费的人时数; ; 维护每种语言的程序平均花费的人时数维护每种语言的程序平均花费的人时数; ; 一张一张MRFMRF

46、的平均周转时间的平均周转时间; ; 各类维护请求的百分比。各类维护请求的百分比。根据这些统计量可对开发技术、编程语言根据这些统计量可对开发技术、编程语言, ,以及对维护以及对维护工作量的预测与资源分配等诸多方面的决策进行评价。工作量的预测与资源分配等诸多方面的决策进行评价。2021-12-22国防科技大学计算机学院3813.5 13.5 维护的副作用维护的副作用软件修改是一项很危险的工作软件修改是一项很危险的工作, ,对一个复杂的逻辑过程对一个复杂的逻辑过程, ,那怕做一项微小的改动那怕做一项微小的改动, ,都可能引入潜在的缺陷都可能引入潜在的缺陷, ,虽然设虽然设计文档化和细致的回归测试有助

47、于排除缺陷计文档化和细致的回归测试有助于排除缺陷, ,但是维护但是维护仍然会产生副作用。软件维护的副作用指，由于维护或仍然会产生副作用。软件维护的副作用指，由于维护或在维护过程中其他一些不期望的行为引入的缺陷在维护过程中其他一些不期望的行为引入的缺陷, ,副作副作用大致可分为三类用大致可分为三类: :(1) (1) 代码副作用。虽然每次代码修改都可能引入潜在的代码副作用。虽然每次代码修改都可能引入潜在的缺陷缺陷, ,但下列修改最易出错但下列修改最易出错: : 修改或删除子程序、语句标号、标识符修改或删除子程序、语句标号、标识符; ; 为提高程序执行效率而做的修改为提高程序执行效率而做的修改;

48、; 修改文件的修改文件的openopen、closeclose操作操作; ; 修改逻辑操作符修改逻辑操作符; ; 由设计变更引起的代码修改由设计变更引起的代码修改; ; 修改对边界条件的测试。修改对边界条件的测试。2021-12-22国防科技大学计算机学院39维护的副作用维护的副作用代码副作用有时通过回归测试即可发现代码副作用有时通过回归测试即可发现, ,此时此时应立即采取补救措施；应立即采取补救措施；不幸的是不幸的是, ,有时直到交付运行后才暴露出来有时直到交付运行后才暴露出来, ,故故对代码进行上述修改应特别慎重。对代码进行上述修改应特别慎重。(2)(2)数据副作用。数据副作用。 在此之前

49、我们曾多次强调软件设计中数据结构在此之前我们曾多次强调软件设计中数据结构的重要性。的重要性。在维护阶段一旦修改了数据结构在维护阶段一旦修改了数据结构, ,软件设计与软件设计与数据可能就不再吻合数据可能就不再吻合, ,缺陷随即出现。缺陷随即出现。数据副作用指，因修改软件的信息结构而带来数据副作用指，因修改软件的信息结构而带来 的不良后果。的不良后果。2021-12-22国防科技大学计算机学院40维护的副作用维护的副作用容易引起数据副作用的修改包括容易引起数据副作用的修改包括: :局部和全局常量、记录或文件格式的再定义局部和全局常量、记录或文件格式的再定义增减数据或其他复杂数据结构的体积增减数据或

50、其他复杂数据结构的体积; ;修改全局数据修改全局数据; ;控制标志和指针的重新初始化控制标志和指针的重新初始化; ;重新排列重新排列I/OI/O表或子程序参数表。表或子程序参数表。设计文档化有助于限制数据副作用设计文档化有助于限制数据副作用, ,因为设计因为设计文档中详细地描述了数据结构并提供一个交叉文档中详细地描述了数据结构并提供一个交叉访问表访问表, ,把数据及引用它们的模块一一对应起把数据及引用它们的模块一一对应起来。来。2021-12-22国防科技大学计算机学院41维护的副作用维护的副作用(3)(3)文档的副作用。文档的副作用。 维护应统一考虑整个软件配置维护应统一考虑整个软件配置,

51、,而不仅仅是源而不仅仅是源代码。否则代码。否则, ,由于在设计文档和用户手册中未由于在设计文档和用户手册中未能准确反映修改情况而引起文档副作用。能准确反映修改情况而引起文档副作用。对软件的任何修改都应在相应的技术文档中反对软件的任何修改都应在相应的技术文档中反映出来映出来, ,如果设计文档不能与软件当前的状况如果设计文档不能与软件当前的状况对应则比没有文档更糟。对应则比没有文档更糟。对用户来说对用户来说, ,若使用说明中未能反映修改后的若使用说明中未能反映修改后的状况状况, ,那么用户在这些问题上必定出错。那么用户在这些问题上必定出错。一次维护完成之后一次维护完成之后, ,再次交付软件之前应仔

52、细再次交付软件之前应仔细复审整个配置复审整个配置, ,有效地减少文档副作用。某些有效地减少文档副作用。某些维护申请不必修改设计和代码维护申请不必修改设计和代码, ,只需整理用户只需整理用户文档便可达到维护的目的。文档便可达到维护的目的。2021-12-22国防科技大学计算机学院4213.6 13.6 逆向工程与软件重构逆向工程与软件重构软件重构是目前预防性维护采用的主要技术，即软件重构是目前预防性维护采用的主要技术，即通过设法提高现有系统的总体质量来应对维护挑通过设法提高现有系统的总体质量来应对维护挑战。战。它涉及文档重构、重组、逆向工程和再工程四个它涉及文档重构、重组、逆向工程和再工程四个层

53、次的工作。层次的工作。文档重构是，通过对源代码进行静态分析帮助维文档重构是，通过对源代码进行静态分析帮助维护人员理解和引用代码。护人员理解和引用代码。重组（重组（restructurerestructure）是，利用转换规则简化内部）是，利用转换规则简化内部表示，将结构不好的代码转换为易于理解和变更表示，将结构不好的代码转换为易于理解和变更的结构化代码。的结构化代码。2021-12-22国防科技大学计算机学院43逆向工程与软件重构逆向工程与软件重构逆向工程逆向工程(reverse engineer)(reverse engineer) 根据源代码构造软件中间制品，包括重新创建设根据源代码构造软

54、件中间制品，包括重新创建设计和规约。计和规约。再工程再工程(reengineering)(reengineering) 在逆向工程所获信息的基础上，重新进行在逆向工程所获信息的基础上，重新进行“正向正向工程工程”，重构已有系统的一个新版本，使其更易，重构已有系统的一个新版本，使其更易维护。维护。通常，再工程软件的质量提高了，但功能没有改通常，再工程软件的质量提高了，但功能没有改变。变。图图13.413.4给出四类软件重构的关系。给出四类软件重构的关系。2021-12-22国防科技大学计算机学院44图图13.4 13.4 软件重构分类软件重构分类2021-12-22国防科技大学计算机学院4513

55、.6.1 13.6.1 文档重构文档重构文档重构是指对源代码进行静态分析以产生系文档重构是指对源代码进行静态分析以产生系统文档。检查变量使用、构件调用、控制路径、统文档。检查变量使用、构件调用、控制路径、构件规模、调用参数、测试路径等帮助我们理构件规模、调用参数、测试路径等帮助我们理解代码解代码“做什么做什么”以及以及“如何做如何做”。静态代码分析产生的这些信息可以用图形或文静态代码分析产生的这些信息可以用图形或文本来表示。本来表示。 图图13.513.5阐明文档重构的过程。阐明文档重构的过程。存在文档分析工具支持文档重构，工具通过分存在文档分析工具支持文档重构，工具通过分析代码，导出构件调用

56、关系、类层次、数据接析代码，导出构件调用关系、类层次、数据接口表、数据字典、数据流表或数据流图、控制口表、数据字典、数据流表或数据流图、控制流表或控制流图、伪代码、测试路径、构件和流表或控制流图、伪代码、测试路径、构件和变量的交叉引用表，等等。变量的交叉引用表，等等。2021-12-22国防科技大学计算机学院46图图13.513.5文档重构过程文档重构过程2021-12-22国防科技大学计算机学院4713.6.213.6.2重组重组重组的目的是为了使代码更易于理解和变更。重组的目的是为了使代码更易于理解和变更。一般利用工具解释源代码并产生内部表示（如一般利用工具解释源代码并产生内部表示（如语义

57、网或有向图），然后利用转换规则简化内语义网或有向图），然后利用转换规则简化内部表示，最后解释简化表示并改写为结构化的部表示，最后解释简化表示并改写为结构化的代码。代码。图图13.6 13.6 展示了三个主要重组活动。展示了三个主要重组活动。尽管一些重组工具仅能产生源代码，但另外一尽管一些重组工具仅能产生源代码，但另外一些工具能支持生成结构，给出容量、复杂性及些工具能支持生成结构，给出容量、复杂性及其他信息。这些测度可用于确定代码的可维护其他信息。这些测度可用于确定代码的可维护性，评估重组的效果。例如，我们总是希望重性，评估重组的效果。例如，我们总是希望重组后的代码复杂性能够降低。组后的代码复杂

58、性能够降低。2021-12-22国防科技大学计算机学院48图图13.6 13.6 重组重组2021-12-22国防科技大学计算机学院4913.6.3 13.6.3 逆向工程逆向工程逆向工程术语源于硬件制造业逆向工程术语源于硬件制造业, ,相互竞争的公相互竞争的公司为了了解对方设计和制造工艺的机密司为了了解对方设计和制造工艺的机密, ,在得在得不到设计和制造说明书的情况下不到设计和制造说明书的情况下, ,通过拆卸实通过拆卸实物获取信息物获取信息, ,软件的逆向工程也基本类似软件的逆向工程也基本类似, ,不过不过通常通常“解剖解剖”的不仅是竞争对手的程序，而且的不仅是竞争对手的程序，而且还包括本公

59、司多年前的制品还包括本公司多年前的制品, ,此时得不到设计此时得不到设计“机密机密”的主要障碍是缺乏文档。因此的主要障碍是缺乏文档。因此, ,所谓所谓软件的逆向工程就是分析已有的程序软件的逆向工程就是分析已有的程序, ,寻求比寻求比源代码更高级的抽象表现形式。一般认为，凡源代码更高级的抽象表现形式。一般认为，凡是在软件生存周期内，将软件某种形式的描述是在软件生存周期内，将软件某种形式的描述转换成更为抽象形式的活动都可称为逆向工程。转换成更为抽象形式的活动都可称为逆向工程。2021-12-22国防科技大学计算机学院50逆向工程逆向工程逆向工程可恢复的信息可分为四个抽象层次：逆向工程可恢复的信息可

60、分为四个抽象层次：(1) (1) 实现级，包括程序模块和变量表、交叉引用实现级，包括程序模块和变量表、交叉引用等信息；等信息；(2) (2) 结构级，包括反映程序分量之间相互依赖关结构级，包括反映程序分量之间相互依赖关系的信息，例如数据和控制流图、结构图等；系的信息，例如数据和控制流图、结构图等；(3) (3) 功能级，包括反映程序段功能及程序段之间功能级，包括反映程序段功能及程序段之间关系的信息，例如处理规约、构件调用层次等；关系的信息，例如处理规约、构件调用层次等；(4) (4) 领域级，包括反映程序分量或程序诸实体与领域级，包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息。应