第13章软件维护
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
2015/10/30 国防科技大学计算机学院 6
软件维护与进化的概念
调查表明：约有65%的维护属完善性维护；18%的
维护属适应性维护；17%的维护属纠错性维护。 修补系统缺陷并不是费用最高的维护活动，适应 新环境的系统进化和实现新需求以及需求变更占 用了绝大部分的维护工作量。 实践中，几类维护之间没有明确界限。 如，在使软件适应新环境的同时，还可能增加新 功能，充分利用该环境提供的服务； 某个软件失误可能是因为系统用事先未预料到的 方式工作，修正这类失误的另一种方法是改变系 统的这种工作方式，等等。
2015/10/30
国防科技大学计算机学院
21
若干量化的测度
⑥ 局部、整体测试耗费的时间; ⑦ 维护复审耗费的时间; ⑧ 系统恢复耗费的时间。 收集上述度量数据作为管理者评估人员、工具、 技术有效性的依据,除了这些面向时间的度量外, 有关设计结构和软件复杂性的度量亦可间接说明 软件的可维护性。
2015/10/30 国防科技大学计算机学院 7
软件维护与进化的概念
在前几章讨论系统开发时，主要关注如何生产能
够实现需求并能正确运行的代码。 维护不仅要理解软件制品，而且要了解用户对系 统运行的意见，预测可能出现的问题，考虑业务 需求变化带来的软件功能的新变更，以及硬件、 软件或接口变更带来的系统变化。 维护涉及的范围更广，内容更多。
2015/10/30 国防科技大学计算机学院 20
13.3.2 若干量化的测度
软件可维护性与软件质量和可靠性一样是难以量
化的概念,然而借助维护活动中可以定量估算的属 性,能间接地度量可维护性。 面向时间的度量包括： ① ② ③ ④ ⑤ 发现问题耗费的时间; 收集维护工具耗费的时间; 分析问题耗费的时间; 形成修改说明书耗费的时间； 纠错(或修改) 耗费的时间;
2015/10/30
国防科技大学计算机学院
9
13.2.1 结构化与非结构化的维护
一个维护需求（申请）被接收后,可能发生的事件
如图13.1所示。如果软件配臵中唯一可用的是源代 码,那么维护只能从“苦读”代码开始。 由于缺乏内部文档,读代码是一项很枯燥、很困难 的工作。 软件系统的许多微妙之处(例如软件总体结构、全 局数据、系统接口、性能和设计方面的约束等 )不 是搞不清楚就是常常被误解,以致无法估量对源代 码修改所产生的后果。特别是，由于没有保存测试 记录,使“回归测试”无法进行。 对于没有使用良好开发方法开发的软件 ,不得不采 用非结构化的方式进行维护并为此付出高昂的代价 (浪费大量人力,让维护人员有挫折感)。
统的交付并不意味着其生存周期的结束。 系统构建之后通常还会不断地变化，我们面临 的挑战是如何维护一个持续演化的系统。 演化可能是由于需求和环境发生变化，也可能 是软件自身暴露出问题。统计和估测结果表明， 信息系统中硬件费用一般占35%，软件费用占 65%，而软件后期维护费用有时竟高达软件总 费用的80%，所有前期开发费用仅占20%。 许多大型软件公司为维护已有软件耗费大量人 力、财力。 必须建立一套评估、控制和实施软件维护的机 制,这就是本章重点讨论的内容。
2015/10/30 国防科技大学计算机学院 3
13.1 软件维护与进化的概念
软件维护是软件交付后，保障软件生产活动，发
挥软件社会和经济效益的关键。 软件交付并投入运行后，任何针对系统变更所做 的工作，都是维护(maintenance)。 软件维护究其原因可分为：纠错性维护、适应性 维护、完善性维护和预防性维护四类。 纠错性维护是为诊断和改正软件系统中潜藏的缺 陷而进行的活动。 测试不可能排除大型软件系统中所有的缺陷,软件 交付后,用户在使用软件的过程中会发现软件潜伏 的缺陷,他们会向开发人员报告并要求维护。
2015/10/30
国防科技大学计算机学院
19
13.3.1影响可维护性的因素
影响软件可维护性的因素：
设计、编码和测试不规范，软件配臵不全 开发环境的因素:
① 训练有素的软件团队； ② 维护团队是否熟悉经过多次维护的系统； ③ 软件的可理解性，包括：软件结构、描述软件制品的语 言（如UML,程序设计语言等）、文档及标准化程度等； ④ 操作系统的标准化程度； ⑤ 维护工具和环境； ⑥ 生成测试用例的能力； ⑦ 对于嵌入式软件系统维护应有专门的调试工具
2015/10/30 国防科技大学计算机学院 18
13.3 可维护性
软件可维护性指,理解、改正、调整和改进软件的
难易程度。 可维护性是软件质量的重要属性，涉及软件开发 方法、工具、过程、软件制品、文档、软件管理、 资金投入、维护计划、维护团队等。 可维护性是指导软件工程活动的一条基本原则， 也是软件工程追求的一个目标。
2015/10/30
国防科技大学计算机学院
22
13.3.3保证可维护性的复审
可维护性是软件质量标准的基本要素。 软件制品的复审活动经常遇到可维护性的内容。 在需求分析制品的复审中,应对将来可能修改
和可以改进的部分进行注释,注意为软件移植 提供方便，并考虑可能影响软件维护的系统界 面; 在设计阶段的复审中,应从易于维护和提高设 计总体质量的角度全面评审数据设计、总体结 构设计、过程设计和界面设计; 代码复审主要强调编程风格和内部文档，他们 是影响可维护性的重要因素;
2015/10/30 国防科技大学计算机学院 5
软件维护与进化的概念
完善性维护是根据用户在软件使用过程中提出的一
些新需求实施的维护活动。 应用软件运行期间,用户可能请求增加新功能、建 议修改已有功能或提出某些改进意见。 完善性维护通常占所有软件维护工作量的一半以上。 预防性维护是优化软件系统结构和可理解性，改善 可维护性和可靠性。 软件长期维护会使体系结构变坏，难以理解，增加 维护费用，降低运行效率。 这类维护活动涉及逆向工程(reverse engineering) 和软件重构。留待13.6节专门讨论。
2015/10/30 国防科技大学计算机学院 13
维护的成本
某些貌似合理但实际不能满足的维护请求将引
起用户不满; 在软件维护过程中引入的潜在缺陷降低了软件 的质量; 从开发小组中临时抽调工程师从事维护工作冲 击正在进行的开发等等。 维护旧程序使生产率(按每人月代码行或每人 月功能点计算)大幅度下降。 据报道,生产率最多可能降低四十倍,即每行用 25元开发的软件，维护一行可能耗费1000元。 在设计和实现时为提高可维护性投资是值得的。
2015/10/30 国防科技大学计算机学院 23
保证可维护性的复审
最后,在软件正式交付之前,应该进行一次预防性
维护，使代码具有良好的结构，并保持文档和代 码的一致性。
2015/10/30
国防科技大学计算机学院
8
13.2
软件维护的过程模型
实践证明，有重要应用价值的软件，生存周期一
般很长，软件维护不可避免。 从软件开发的螺旋模型看,软件维护是软件开发的 继续,是软件的进化。 多数维护团队已不再是该软件的开发团队，软件 维护面临许多困难。 本节主要讨论软件维护的主要内容、软件工程的 目标原则对这些活动的影响、软件维护的成本、 软件维护存在的问题等。
2015/10/30 国防科技大学计算机学院 17
可能存在的问题
(5)软件没有文档、或文档不全、或文档不易理解、 或与源代码不一致；
(6)多数软件设计未考虑修改的需要(有些设计方法 采用了功能独立和对象类型等一些便于修改的概 念),软件修改不仅困难而且容易出错。 (7)软件维护不是一项有吸引力的工作,从事这项工 作令人缺乏成就感。 许多遗留系统未采用软件工程的思想和方法开发 (大都运行了十年以上),问题尤其严重。 下面从技术和管理的角度讨论解决这些问题的具 体措施。
2015/10/30 国防科技大学计算机学院 4
软件维护与进化的概念
维护人员找出软件失效的原因，进行改正，并根据
需要对需求、设计、代码、测试序列以及文档做出 相应变更。 最初的修改可能是临时性的，即为保持系统运行所 采取的一些应急措施。 事后应对维护方案仔细推敲，在软件工具的支持下 进行回归测试，自动修改相应的文档。 适应性维护是为适应软件运行环境变化，如操作系 统变更、硬件更新，而修改软件的活动。 应用软件的使用寿命很长，多数超过十年 ,但运行 环境更新通常不会超过十年,CPU基本是一年半一代, 操作系统不断地推出新版本,外部设备和其他系统 元素也频繁升级和变化,因此适应性维护是十分必 要的。
2015/10/30 国防科技大学计算机学院 15
维护的成本
下面给出维护工作量的一种估算模型:
M=P+K*e(c-d)
（13-1）
其中 M表示维护工作量，P表示生产性工作量，K为经 验常数 c表示复杂度,标志设计的好坏及文档完整程度 d表示对维护软件的熟悉程度 模型表明,倘若未用好的软件开发方法(即未遵 循软件工程的思想)或软件开发人员不能参与 维护,则维护工作量(和成本)将成指数增长。
2015/10/30 国防科技大学计算机学院 16
13.2.3
可能存在的问题
软件维护中出现的大部分问题都可归咎于软件规划
和开发方法的缺陷。 软件开发若不严格遵循软件开发标准,软件维护就 会遇到许多困难。 影响维护的问题: (1)很难甚至不可能追踪软件版本的进化过程 ,软件的 变化没在相应文档中反映出来; (2)很难甚至不可能追踪软件的整个创建过程； (3)理解他人的程序非常困难,当软件配臵不全,仅有 源代码时问题尤为严重; (4)软件人员流动性很大,维护他人软件时很难得到开 发者的帮助；
2015/10/30 国防科技大学计算机学院 10
图 13.1 非 结 构 化 与 结 构 化 维 护
2015/10/30 国防科技大学计算机学院 11
结构化与非结构化的维护
如果欲维护的软件存在一个完整的软件配臵,
维护活动将从阅读设计文档开始。首先确定软 件的重要结构、性能及接口特征,评估这次维 护可能带来的影响并规划出一个具体实施方案; 然后从修改设计入手(采用以前讨论过的设计 技术)，设计复审通过之后再修改代码,并参照 测试规格说明书对软件进行回归测试,测试通 过后交付用户使用。 上述过程也称为结构化维护,它是采用软件工 程方法学开发软件的自然结果。拥有完整的软 件配臵能减少维护工作量，提高维护质量。
2015/10/30 国防科技大学计算机学院 14
维护的成本
维护成本与开发成本的比例在不同应用领域中是
不同的。 对于业务应用系统，维护费用与系统开发成本大 体相等。 对于嵌入式实时系统，维护费用能达到开发成本 的四倍以上，这类系统的高可靠性和高性能需求 需要模块间紧密连接，因此变更起来特别困难。 软件维护工作量分为生产性(用于分析与评价，修 改设计和代码等)和助动性(用于理解代码功能， 解释数据结构、接口特征与性能约束等)两类。
2015/10/30 国防科技大学计算机学院 12
13.2.2 维护的成本
过去的四十年,软件维护的成本在不断wk.baidu.com长。
20世纪70年代,一个信息系统机构用于软件维
护的费用占其软件总预算的35～40% 80年代接近60%若维护方式没有大的改进,未来 几年，许多大型软件公司可能要将其预算的 80%用于软件系统的维护上。 除软件维护耗费的财力外,其他因素也引起人 们的注意。 如,由于资源(人力、设备)优先用于维护任务, 影响新软件系统的开发，要付出无形的代价。
软件工程(第三版)
第十三章 软件维护
齐治昌 谭庆平 宁洪
第十三章
13.1 13.2 13.3 13.4 13.5 13.6
软件维护
软件维护与进化的概念 软件维护的过程模型 可维护性 维护活动及实施策略 维护的副作用 逆向工程与软件重构
2015/10/30
国防科技大学计算机学院
2
软件维护
我们讨论了构建一个软件系统的全过程，但系
软件维护与进化的概念
调查表明：约有65%的维护属完善性维护；18%的
维护属适应性维护；17%的维护属纠错性维护。 修补系统缺陷并不是费用最高的维护活动，适应 新环境的系统进化和实现新需求以及需求变更占 用了绝大部分的维护工作量。 实践中，几类维护之间没有明确界限。 如，在使软件适应新环境的同时，还可能增加新 功能，充分利用该环境提供的服务； 某个软件失误可能是因为系统用事先未预料到的 方式工作，修正这类失误的另一种方法是改变系 统的这种工作方式，等等。
2015/10/30
国防科技大学计算机学院
21
若干量化的测度
⑥ 局部、整体测试耗费的时间; ⑦ 维护复审耗费的时间; ⑧ 系统恢复耗费的时间。 收集上述度量数据作为管理者评估人员、工具、 技术有效性的依据,除了这些面向时间的度量外, 有关设计结构和软件复杂性的度量亦可间接说明 软件的可维护性。
2015/10/30 国防科技大学计算机学院 7
软件维护与进化的概念
在前几章讨论系统开发时，主要关注如何生产能
够实现需求并能正确运行的代码。 维护不仅要理解软件制品，而且要了解用户对系 统运行的意见，预测可能出现的问题，考虑业务 需求变化带来的软件功能的新变更，以及硬件、 软件或接口变更带来的系统变化。 维护涉及的范围更广，内容更多。
2015/10/30 国防科技大学计算机学院 20
13.3.2 若干量化的测度
软件可维护性与软件质量和可靠性一样是难以量
化的概念,然而借助维护活动中可以定量估算的属 性,能间接地度量可维护性。 面向时间的度量包括： ① ② ③ ④ ⑤ 发现问题耗费的时间; 收集维护工具耗费的时间; 分析问题耗费的时间; 形成修改说明书耗费的时间； 纠错(或修改) 耗费的时间;
2015/10/30
国防科技大学计算机学院
9
13.2.1 结构化与非结构化的维护
一个维护需求（申请）被接收后,可能发生的事件
如图13.1所示。如果软件配臵中唯一可用的是源代 码,那么维护只能从“苦读”代码开始。 由于缺乏内部文档,读代码是一项很枯燥、很困难 的工作。 软件系统的许多微妙之处(例如软件总体结构、全 局数据、系统接口、性能和设计方面的约束等 )不 是搞不清楚就是常常被误解,以致无法估量对源代 码修改所产生的后果。特别是，由于没有保存测试 记录,使“回归测试”无法进行。 对于没有使用良好开发方法开发的软件 ,不得不采 用非结构化的方式进行维护并为此付出高昂的代价 (浪费大量人力,让维护人员有挫折感)。
统的交付并不意味着其生存周期的结束。 系统构建之后通常还会不断地变化，我们面临 的挑战是如何维护一个持续演化的系统。 演化可能是由于需求和环境发生变化，也可能 是软件自身暴露出问题。统计和估测结果表明， 信息系统中硬件费用一般占35%，软件费用占 65%，而软件后期维护费用有时竟高达软件总 费用的80%，所有前期开发费用仅占20%。 许多大型软件公司为维护已有软件耗费大量人 力、财力。 必须建立一套评估、控制和实施软件维护的机 制,这就是本章重点讨论的内容。
2015/10/30 国防科技大学计算机学院 3
13.1 软件维护与进化的概念
软件维护是软件交付后，保障软件生产活动，发
挥软件社会和经济效益的关键。 软件交付并投入运行后，任何针对系统变更所做 的工作，都是维护(maintenance)。 软件维护究其原因可分为：纠错性维护、适应性 维护、完善性维护和预防性维护四类。 纠错性维护是为诊断和改正软件系统中潜藏的缺 陷而进行的活动。 测试不可能排除大型软件系统中所有的缺陷,软件 交付后,用户在使用软件的过程中会发现软件潜伏 的缺陷,他们会向开发人员报告并要求维护。
2015/10/30
国防科技大学计算机学院
19
13.3.1影响可维护性的因素
影响软件可维护性的因素：
设计、编码和测试不规范，软件配臵不全 开发环境的因素:
① 训练有素的软件团队； ② 维护团队是否熟悉经过多次维护的系统； ③ 软件的可理解性，包括：软件结构、描述软件制品的语 言（如UML,程序设计语言等）、文档及标准化程度等； ④ 操作系统的标准化程度； ⑤ 维护工具和环境； ⑥ 生成测试用例的能力； ⑦ 对于嵌入式软件系统维护应有专门的调试工具
2015/10/30 国防科技大学计算机学院 18
13.3 可维护性
软件可维护性指,理解、改正、调整和改进软件的
难易程度。 可维护性是软件质量的重要属性，涉及软件开发 方法、工具、过程、软件制品、文档、软件管理、 资金投入、维护计划、维护团队等。 可维护性是指导软件工程活动的一条基本原则， 也是软件工程追求的一个目标。
2015/10/30
国防科技大学计算机学院
22
13.3.3保证可维护性的复审
可维护性是软件质量标准的基本要素。 软件制品的复审活动经常遇到可维护性的内容。 在需求分析制品的复审中,应对将来可能修改
和可以改进的部分进行注释,注意为软件移植 提供方便，并考虑可能影响软件维护的系统界 面; 在设计阶段的复审中,应从易于维护和提高设 计总体质量的角度全面评审数据设计、总体结 构设计、过程设计和界面设计; 代码复审主要强调编程风格和内部文档，他们 是影响可维护性的重要因素;
2015/10/30 国防科技大学计算机学院 5
软件维护与进化的概念
完善性维护是根据用户在软件使用过程中提出的一
些新需求实施的维护活动。 应用软件运行期间,用户可能请求增加新功能、建 议修改已有功能或提出某些改进意见。 完善性维护通常占所有软件维护工作量的一半以上。 预防性维护是优化软件系统结构和可理解性，改善 可维护性和可靠性。 软件长期维护会使体系结构变坏，难以理解，增加 维护费用，降低运行效率。 这类维护活动涉及逆向工程(reverse engineering) 和软件重构。留待13.6节专门讨论。
2015/10/30 国防科技大学计算机学院 13
维护的成本
某些貌似合理但实际不能满足的维护请求将引
起用户不满; 在软件维护过程中引入的潜在缺陷降低了软件 的质量; 从开发小组中临时抽调工程师从事维护工作冲 击正在进行的开发等等。 维护旧程序使生产率(按每人月代码行或每人 月功能点计算)大幅度下降。 据报道,生产率最多可能降低四十倍,即每行用 25元开发的软件，维护一行可能耗费1000元。 在设计和实现时为提高可维护性投资是值得的。
2015/10/30 国防科技大学计算机学院 23
保证可维护性的复审
最后,在软件正式交付之前,应该进行一次预防性
维护，使代码具有良好的结构，并保持文档和代 码的一致性。
2015/10/30
国防科技大学计算机学院
8
13.2
软件维护的过程模型
实践证明，有重要应用价值的软件，生存周期一
般很长，软件维护不可避免。 从软件开发的螺旋模型看,软件维护是软件开发的 继续,是软件的进化。 多数维护团队已不再是该软件的开发团队，软件 维护面临许多困难。 本节主要讨论软件维护的主要内容、软件工程的 目标原则对这些活动的影响、软件维护的成本、 软件维护存在的问题等。
2015/10/30 国防科技大学计算机学院 17
可能存在的问题
(5)软件没有文档、或文档不全、或文档不易理解、 或与源代码不一致；
(6)多数软件设计未考虑修改的需要(有些设计方法 采用了功能独立和对象类型等一些便于修改的概 念),软件修改不仅困难而且容易出错。 (7)软件维护不是一项有吸引力的工作,从事这项工 作令人缺乏成就感。 许多遗留系统未采用软件工程的思想和方法开发 (大都运行了十年以上),问题尤其严重。 下面从技术和管理的角度讨论解决这些问题的具 体措施。
2015/10/30 国防科技大学计算机学院 4
软件维护与进化的概念
维护人员找出软件失效的原因，进行改正，并根据
需要对需求、设计、代码、测试序列以及文档做出 相应变更。 最初的修改可能是临时性的，即为保持系统运行所 采取的一些应急措施。 事后应对维护方案仔细推敲，在软件工具的支持下 进行回归测试，自动修改相应的文档。 适应性维护是为适应软件运行环境变化，如操作系 统变更、硬件更新，而修改软件的活动。 应用软件的使用寿命很长，多数超过十年 ,但运行 环境更新通常不会超过十年,CPU基本是一年半一代, 操作系统不断地推出新版本,外部设备和其他系统 元素也频繁升级和变化,因此适应性维护是十分必 要的。
2015/10/30 国防科技大学计算机学院 15
维护的成本
下面给出维护工作量的一种估算模型:
M=P+K*e(c-d)
（13-1）
其中 M表示维护工作量，P表示生产性工作量，K为经 验常数 c表示复杂度,标志设计的好坏及文档完整程度 d表示对维护软件的熟悉程度 模型表明,倘若未用好的软件开发方法(即未遵 循软件工程的思想)或软件开发人员不能参与 维护,则维护工作量(和成本)将成指数增长。
2015/10/30 国防科技大学计算机学院 16
13.2.3
可能存在的问题
软件维护中出现的大部分问题都可归咎于软件规划
和开发方法的缺陷。 软件开发若不严格遵循软件开发标准,软件维护就 会遇到许多困难。 影响维护的问题: (1)很难甚至不可能追踪软件版本的进化过程 ,软件的 变化没在相应文档中反映出来; (2)很难甚至不可能追踪软件的整个创建过程； (3)理解他人的程序非常困难,当软件配臵不全,仅有 源代码时问题尤为严重; (4)软件人员流动性很大,维护他人软件时很难得到开 发者的帮助；
2015/10/30 国防科技大学计算机学院 10
图 13.1 非 结 构 化 与 结 构 化 维 护
2015/10/30 国防科技大学计算机学院 11
结构化与非结构化的维护
如果欲维护的软件存在一个完整的软件配臵,
维护活动将从阅读设计文档开始。首先确定软 件的重要结构、性能及接口特征,评估这次维 护可能带来的影响并规划出一个具体实施方案; 然后从修改设计入手(采用以前讨论过的设计 技术)，设计复审通过之后再修改代码,并参照 测试规格说明书对软件进行回归测试,测试通 过后交付用户使用。 上述过程也称为结构化维护,它是采用软件工 程方法学开发软件的自然结果。拥有完整的软 件配臵能减少维护工作量，提高维护质量。
2015/10/30 国防科技大学计算机学院 14
维护的成本
维护成本与开发成本的比例在不同应用领域中是
不同的。 对于业务应用系统，维护费用与系统开发成本大 体相等。 对于嵌入式实时系统，维护费用能达到开发成本 的四倍以上，这类系统的高可靠性和高性能需求 需要模块间紧密连接，因此变更起来特别困难。 软件维护工作量分为生产性(用于分析与评价，修 改设计和代码等)和助动性(用于理解代码功能， 解释数据结构、接口特征与性能约束等)两类。
2015/10/30 国防科技大学计算机学院 12
13.2.2 维护的成本
过去的四十年,软件维护的成本在不断wk.baidu.com长。
20世纪70年代,一个信息系统机构用于软件维
护的费用占其软件总预算的35～40% 80年代接近60%若维护方式没有大的改进,未来 几年，许多大型软件公司可能要将其预算的 80%用于软件系统的维护上。 除软件维护耗费的财力外,其他因素也引起人 们的注意。 如,由于资源(人力、设备)优先用于维护任务, 影响新软件系统的开发，要付出无形的代价。
软件工程(第三版)
第十三章 软件维护
齐治昌 谭庆平 宁洪
第十三章
13.1 13.2 13.3 13.4 13.5 13.6
软件维护
软件维护与进化的概念 软件维护的过程模型 可维护性 维护活动及实施策略 维护的副作用 逆向工程与软件重构
2015/10/30
国防科技大学计算机学院
2
软件维护
我们讨论了构建一个软件系统的全过程，但系