软件工程第13章软件维护

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