Se2009 ch8
- 1. 作业（第 7 章） 语句覆盖的测试用例 预期的输 序 判定 输入 出 号 1 2 3 A B C X Y Z 1 F F F 1 1 1 1 2 3 2 T T T 20 40 60 10 20 30
- 2. 作业（第 7 章） 路径覆盖的测试用例 预期的输 序 判定 输入 出 号 1 2 3 A B C X Y Z 1 F F F 1 1 1 1 2 3 2 F F T 1 1 60 1 2 30 3 F T F 1 40 1 1 20 3 4 F T T 1 40 60 1 20 30 5 T F F 20 1 1 10 2 3 6 T F T 20 1 60 10 2 30 7 T T F 20 40 1 10 20 3 8 T T T 20 40 60 10 20 30
- 3. 第八章 软 件 维 护 普通人轻视软件维护工作， 会失掉极其宝贵的 机会； 维护人员轻视软件维护工作， 会失掉本应精彩的 人生； 老板轻视软件维护工作， 会丢掉大片本来属于自己 的市场……
- 4. 第八章 软件维护 8. 1 软件维护的定义 软件维护 - - - - 就是在软件已经交付使 用之后，为保证软件在相当长的时期能够 正常运作所进行的软件活动。 维护的类型有四种 ： 改正性维护 适应性维护 完善性维护 预防性维护
- 5. 改正性维护 --- Corrective Maintenance • 在软件交付使用后，因开发时测试的 不彻底、不完全，必然会有部分隐藏 的错误遗留到运行阶段。 • 在任何大型程序的使用期间，用户必 然会发现程序错误，并且把他们遇到 的问题报告给维护人员。 • 为了识别和纠正软件错误、改正软件 性能上的缺陷、排除实施中的误使用 ，所进行的诊断和改正错误的过程就 叫做改正性维护。
- 6. 适应性维护 --- Adaptive Maintenance • 在使用过程中， – 外部环境（新的硬、软件配置）可 能发生变化。 – 增加或修改外部设备和其他系统部件 – 应用软件的使用寿命远远长于最初开 发这个软件时的运行环境的寿命 • 为使软件适应这种变化，而去修改软件 的过程就叫做适应性维护。
- 7. 完善性维护 --- Perfective Maintenance • 在软件的使用过程中，用户往往会对软 件提出新的功能与性能要求。 • 为了满足这些要求，需要修改或再开发 软件，以扩充软件功能、增强软件性能 、改进加工效率、提高软件的可维护性 。 • 这种情况下进行的维护活动叫做完善性 维护。
- 8. 预防性维护 --- Preventive Maintenance • 预防性维护是为了提高软件的可 维护性、可靠性等，为以后进一 步改进软件打下良好基础。 • 预防性维护定义为：采用先进的 软件工程方法对需要维护的软件 或软件中的某一部分（重新）进 行设计、编制和测试。
- 9. 各种维护所占比 例: 改正性维护 适应性维 其它维护 4 17% ～ % 护 21% 18% ～ 25% 完善性维护 50% ～ 66%
- 10. 用户的维护请 结构化维护 求 非结构化维护 研读设计 配置 苦读代码 计划实施途径 理解 ？ 修改设计 重新编写代码 复审 测 重新编写代码 试 回归测试 交付用户使用 交付用户使用
- 11. 8.2 软件维护的特点 -- 影 响维护工作量的因素 • 系统大小：系统越大，理解掌握起来 越困难。系统越大，所执行功能越复 杂。因而需要更多的维护工作量。 • 程序设计语言：使用强功能的程序设 计语言可以控制程序的规模。语言的 功能越强，生成程序的模块化和结构 化程度越高，所需的指令数就越少， 程序的可读性越好。
- 12. • 系统年龄： – 老系统随着不断的修改，结构越来越乱； – 维护人员经常更换，程序又变得越来越难于 理解 – 许多老系统在当初并未按照软件工程的要求 进行开发，因而没有文档，或文档太少。 – 在长期的维护过程中文档在许多地方与程序 实现变得不一致，在维护时就会遇到很大困 难。
- 13. • 先进的软件开发技术：在软件开发时，若使 用能使软件结构比较稳定的分析与设计技术 ，及程序设计技术，如面向对象技术、复用 技术等，可减少大量的工作量。 • 其它： – 应用的类型 – 数学模型 – 任务的难度 对维护工作量都有影响。 • 许多软件在开发时并未考虑将来的修改，为 软件的维护带来许多问题。
- 14. 二 . 维护的成本 • 维护成本占软件总预算的比例不断增加： 70 年代： 35 ％－ 40 ％ 80 年代： 40 ％～ 60 ％ 现在： 80 ％甚至更多 • 软件维护的工作量可分为二类： 生产性： 用于分析和评价软件系统，修改软件 设计和代码 非生产性： 用于理解代码功能、结构特征以及性
- 15. 维护成本 • 有形的软件维护成本是花费了多 少钱，无形的维护成本有更大的 影响。 – 可用的资源必须供维护任务使用 , 以 致耽误甚至丧失开发的良机 ; – 一些合理的修复或修改请求不能及 时安排，使得客户不满意； – 变更的结果引入新的故障，使得软 件整体质量下降； – 把软件人员抽调到维护工作中，干 扰了软件开发工作。
- 16. 维护工 c−d M = p + Ke 作量的 • M 是维护中消耗的总工作量 模型 • P 是生产性工作量 • K 是一个经验常数 • c 是因缺乏好的设计和文档而导致复杂性的度量 • d 是维护人员对软件熟悉程度的度量 • 模型指明，如果使用了不好的软件开发方法 （未按软件工程要求做），原来参加开发的人 员或小组不能参加维护，则工作量（及成本） 将按指数级增加。
- 17. 8.2.3 维护中的典型问题 ( 1) 难以读懂他人程序 . ( 2) 无合格的文档或不全 . ( 3) 软件人员流动性大 . ( 4) 设计时未考虑修改需要 , 修改困难 . ( 5) 维护工作无吸引力 , 缺乏 成就感 . 采用软件工程方法至少可部分地解 决与维护有关的每一个问题。
- 18. 8.3 软件维护过程 • 维护过程本质上是修改和压缩了的软件定义和 开发过程，而且事实上远在提出一项维护要求 之前，与软件维护有关的工作已经开始了。 • 为了有效地进行软件维护，应事先就开始做组 织工作。 – 首先建立维护组织 – 确定维护报告的过程及评价的过程 – 为每一个维护申请规定标准的处理步骤 – 建立维护活动的记录保管过程 – 并规定复审的标准
- 19. 1 、维护组织 • 除了较大的软件开发公司外， 通常在软件维护工作方面，并 不保持一个正式的组织机构。 • 虽然不要求建立一个正式的维 护机构，但是在开发部门确立 一个非正式的维护机构则是非 常必要的。
- 20. 1 、维护组织 决定是否采 取行动（如 人员配置、 任务的分配 维护申请 对修改 ） 进行评 接受维 估 护申请 维护管理员 系统管理员 变化授权人 • 每个维护要求都通过维护管理员转交给相应的系 统管理员去评价（系统管理员是被指定去熟悉一 小部分产品程序的技术人员）。 • 系统管理员对维护任务做出评价之后，由变化授 权人决定应该进行的活动。
- 21. 2. 维护报告 • 应该用标准化的格式表达所有软件维 护申请（要求）。 • 维护申请报告或称软件问题报告，由 申请维护的用户填写。 • 用户必须完整地说明产生错误的情况 ，包括输入数据、错误清单以及其它 有关材料。 • 如果申请的是适应性维护或完善性维 护，用户必须提出一份修改说明书， 列出所有希望的修改。
- 22. • 维护申请报告将由维护管理员和系统管理 员来评价。 • 他们应相应地做出软件修改报告，指明： – 所需修改变动的性质； – 申请修改的优先级； – 为满足某个维护申请报告，所需的工 作量 – 预计修改后的数据 . • 软件修改报告应提交给变化授权人（修改 负责人），经批准后才能开始进一步安排 维护工作。
- 23. 3. 维护的事件流 23
- 24. • 尽管维护类型不同，但都要进行同样的技术工作 。 – 修改软件需求说明 – 修改软件设计 – 设计评审 – 对源程序做必要的修改 – 单元测试 – 集成测试 ( 回归测试 ) – 确认测试 – 软件配置评审等。
- 25. 在软件维护任务完成后进行处境复查，对 以下问题做一总结： (1 ) 在目前处境下，设计、编码、测试中 的哪一方面可以改进 ? (2) 哪些维护资源应该有但没有 ? (3) 维护工作中主要的或次要的障碍是什 么? (4) 从维护类型来看是否应当有预防性维 护? 处境复查对将来的维护工作如何进行会产生
- 26. 4 、保存维护记录 • 记录维护活动过程中的各种信息，如增加 源程序的行数，耗费的人力、财力、利润 。 • 目的： 估算维护技术的有效性和实际成 本
- 27. 4 、保存维护记录 ① 程序标识； ②源语 ⑽ 因程序变动而删除 句数； ③机器指令条数 的源语句数； ⑾ 每个 ； ④使用的程序设计语 改动耗费的人时数； ⑿ 程序改动的日期； 言； ⑤程序安装的日期 ⒀ 软件工程师的名字 ； ⑥自从安装以来程序 ； ⒁ 维护要求表的标 运行的次数； ⑦自从安 识； ⒂ 维护类型； 装以来程序失效的次数 ⒃ 维护开始和完成的 ； ⑧程序变动的层次和 日期； ⒄ 累计用于维 标识； ⑨因程序变动而 护的人时数； ⒅ 与完 增加的源语句数； 成的维护相联系的纯效 益。
- 28. 5 、评价维护活动 • 评价维护活动比较困难，因为缺乏可靠的数据。 • 如果维护记录做得比较好，可以得出一些维护工作的定 量度量。 ( 1) 每次程序运行平均失效的次数； ( 2) 用于每一类维护活动的总人时数； ( 3) 平均每个程序、每种语言、每种维护类型所做的 程序变动数； ( 4) 维护过程中增加或删除一个源语句平均花费的人 时数； ( 5) 维护每种语言平均花费的人时数； ( 6) 一张维护要求表的平均周转时间； ( 7) 不同维护类型所占的百分比。 • 根据对维护工作定量度量的结果，可以做出关于开发技 术、语言选择、维护工作量规划、资源分配及其他许多 方面的决定，而且可以利用这样的数据去分析评价维护
- 29. 8.4 软件的可维护性 • 许多软件的维护十分困难，原因在于这些软 件的文档不全、质量差、开发过程不注意采 用好的方法，忽视程序设计风格等。 • 许多维护要求并不是因为程序中出错而提出 的，而是为适应环境变化或需求变化而提出 的。 • 为了使得软件能够易于维护，必须考虑使软 件具有可维护性。 • 软件可维护性是指纠正软件系统出现的错误 和缺陷，以及为满足新的要求进行修改、扩 充或压缩的容易程度。
- 30. • 目前广泛使用的是用如下的五个 特性来衡量程序的可维护性。 可理解性 可测试性 可修改性 可移植性 可重用性
- 31. 8.4.1 决定软件可维护性的因素 1. 可理解性 • 可理解性表明人们通过阅读源代码 和相关文档，了解程序功能及其如 何运行的容易程度。 • 一个可理解的程序应具备以下一些 特性： 模块化 ， 风格一致性 ， 不使 用令人捉摸不定或含糊不清的代码 ， 使用有意义的数据名和过程名 ， 结构化 ， 完整性 等。
- 32. 2. 可测试 性 • 可测试性表明程序容易测试程度。而 且设计合用的测试用例，取决于对程 序的全面理解。 • 一个可测试的程序应当是可理解的， 可靠的，简单的。 • 用于可测试性度量的检查项目如下： – 程序是否模块化 ? 结构是否良好 ?
- 33. – 程序是否可理解 ? 程序是否可靠 ? – 程序是否能显示任意中间结果 ? – 程序是否能以清楚的方式描述它 的输出 ? – 程序是否能及时地按照要求显示 所有的输入 ? – 程序是否有跟踪及显示逻辑控制 流程的能力 ? – 程序是否能从检查点再启动 ? – 程序是否能显示带说明的错误信 息?
- 34. 3. 可修改 性 • 可修改性表明程序容易修改的程度 。 • 与本书第 5 章讲过的设计原理和启 发规则直接有关。耦合、内聚、信 息隐藏、局部化、控制域与作用域 的关系等等，都影响软件的可修改 性。
- 35. 4. 可移植 性 • 可移植性表明程序转移到一个新的 计算环境的难易程度 。或者它表明 程序可以容易地、有效地在各种各 样的计算环境中运行的容易程度。 • 一个可移植的程序应具有 结构良好 、 灵活 、 不依赖于某一具体计算机 或操作系统的性能 。 • 用于可移植性度量的检查项目如下 ：
- 36. – 是否是用高级的独立于机器的语言 来编写程序 ? – 是否仅使用了这种语言的标准版本和 特性 ? – 程序中是否使用了标准的普遍使用 的库功能和子程序 ? – 程序中是否极少使用或根本不使用 操作系统的功能 ? – 程序是否把与机器相关的语句分离 了出来，集中放在了一些单独的程序 模块中，并有说明文件 ?
- 37. 5. 可重用 性 • 重用（ reuse ）是指同一事物不做修改或 稍加改动就在不同环境中多次重复使用。 大量使用可重用的软件构件来开发软件， 可以从下述两个方面提高软件的可维护性 ： (1) 通常，可重用的软件构件在开发时经 过很严格的测试，可靠性比较高，且在每 次重用过程中都会发现并清除一些错误， 随着时间推移，这样的构件将变成实质上 无错误的。因此，软件中使用的可重用构 件越多，软件的可靠性越高，改正性维护 需求越少。
- 38. （ 2 ） 很容易修改可重用的软件 构件使之再次应用在新环境中，因 此，软件中使用的可重用构件越多 ，适应性和完善性维护也就越容易 。 • 而且对于不同类型的维护，这五 种特性的侧重点也不相同。 种特性的侧重点也不相同
- 39. 在各类维护中的侧重点 改正性维护 适应性维护 完善性维护 可理解性 √ 可测试性 √ 可修改性 √ √ 可移植性 √ 可重用性 √ √
- 40. 8.4.2 文 档 • 文档是影响软件可维护性的决定 因素。往往文档比程序代码更重 要。 • 软件系统的文档可以分为用户文 档和系统文档两类。 - - - - 用户文档主要描述系统功 能和使用方法，并不关心这些功 能是怎样实现的； - - - - 系统文档描述系统设计、 实现和测试等各方面的内容。
- 41. • 软件文档应该满足下述要求： ( 1) 必须描述如何使用这个系统，没 有这种描述时即使是最简单的系统也 无法使用； ( 2) 必须描述怎样安装和管理这个系 统； ( 3) 必须描述系统需求和设计； ( 4) 必须描述系统的实现和测试，以 便使系统成为可维护的。
- 42. 1. 用户文档 用户文档是用户了解系统的第一步，它应该 能使用户获得对系统的准确的初步印象。文档 的结构方式应该使用户能够方便地根据需要阅 读有关的内容。 用户文档至少应该包括下述 5 方面的内容： ( 1) 功能描述； ( 2) 安装文档； ( 3) 使用手册； ( 4) 参考手册； ( 5) 操作员指南 ( 如果需要有系统操作员 的话 ) 。 上述内容可以分别作为独立的文档， 也可以作为一个文档的不同分册， 具体做法应该由系统规模决定。 42
- 43. 2. 系统文档 - - - - 所谓系统文档指从问题定义、需 求说明到验收测试计划这样一系列和系统 实现有关的文档。 - - - - 描述系统设计、实现和测试的文 档对于理解程序和维护程序来说是极端重 要的。 - - - - 和用户文档类似，系统文档的结 构也应该能把读者从对系统概貌的了解， 引导到对系统每个方面每个特点的更形式 化更具体的认识。
- 44. 8.4.3 可维护性复审 • 在软件工程过程的每一个阶段都应该考虑并努 力提高软件的可维护性，在每个阶段结束前的 技术审查和管理复审中，应该着重对可维护性 进行复审。
- 45. • 在完成了每项维护工作之后，都应该对软件维护本身 进行仔细认真的复审。 - - - 维护应该针对整个软件配置，不应该只修改源 程序代码。当对源程序代码的修改没有反映在设计文 档或用户手册中时，就会产生严重的后果。 - - - 每当对数据、软件结构、模块过程或任何其他 有关的软件特点做了改动时，必须立即修改相应的技 术文档。不能准确反映软件当前状态的设计文档可能 比完全没有文档更坏。 - - - 用户通常根据描述软件特点和使用方法的用户 文档来使用、评价软件。如果对软件的可执行部分的 修改没有及时反映在用户文档中，则必然会使用户因 为受挫折而产生不满。
- 46. 8.5 预防性维护 • 预防性维护方法是由 Mille r 提出来的， 他把这种方法定义为：“ 把今天的方法 学应用到昨天的系统上，以支持明天的 需求。” • 开发和维护者不应等待用户的维护申请 , 在条件具备时应该主动地进行预防性 维护。 • 预防性维护对象 : • 预计若干年内将继续使用的程序 • 当今正成功使用的程序
- 47. 8.6 软件再工程过程（ Software Reengineering ） • 再工程是一个重构活动（ 类比 重建一所房子） 开始重建前，首先检查一下房子。确定它是否确实 需要重建？ 在拆掉并重建房子前，确定其结构是否牢固。若结 构良好，则可能是“改造”。 在开始重建前，确保你已经了解房子最初是如何建 造的。（墙内部，了解布线、管道以及内部结构。 ） 如果决定重建，一定要采用严格的方式，使用现在 及将来都将获得高质量的做法。 如果开始重建，应该使用最现代的，耐久的材料。
- 48. 8.6 软件再工程过程 （ Software Reengineering ） 软件再工程是一类 软件工程活动，是 一个工程过程 , 它 将逆向工程、重构 和正向工程组合起 来 , 将现存系统重 新构造为新的形式 。 软件再工程过程模型
- 49. 软件再工程过程模型所定义的 6 类活动 1. 库存目录分析 2. 文档重构 3. 逆向工程 4. 代码重构 5. 数据重构 6. 正向工程
- 50. 1. 库存目录分析 对软件组织的每个应用系统都进行预防 性维护是不现实的，也是不必要的。一般说 来，下述 3 类程序有可能成为预防性维护的 对象： 该程序将在今后数年内继续维护的对象 当前正在成功地使用着该程序 可能在最近的将来要对该程序做较大程度
- 52. 2. 文档重构 老程序固有的特点缺乏文档，根据具体 情况可采用下述 3 种方法之一来处理这个 问题： 1) 如果一个程序是相对稳定的，正在走 向生命的终点，而且可能不会再修改它， 则不必为它建立文档。
- 53. 2) 为了便于今后的维护，必须更新文 档，但是由于资源有限，应该采用 “ 使用时 建立文档 ” 的方法，也就是说，不是一下子 把某应用系统的文档全部都重建起来，而 是只建立系统中当前正在修改的那些部分 的完整文档。 3) 如果某应用系统是用户完成业务工 作的关键，而且必须重构全部文档，则仍
- 56. 5. 数据重构 对数据体系结构差的程序很难进行适 应性和完善性维护，因此，数据体系结构 比源代码对程序的长期生存力有更大的影 响。 数据重构是一种全范围的再工程活动。 由于数据结构对程序体系结构及程序中 的算法有很大影响，对数据的修改必然会
- 57. 6. 正向工程 正向工程也称为更新或再造。 正向工程过程应用现代软件工程的概 念、原理、技术和方法，重新开发现有 的某些应用系统。 在大多数情况下，经过正向工程过程 后的软件，不仅重新实现了现有系统的 功能，而且增加了新功能，提高了整体 性能。
- 58. 本章小结 • 软件维护的 4 类活动 （改正性、适应性、完善性、预防性） • 决定软件可维护性的基本要素 （可理解、可测试、可修改、可移植和 可重用性） • 文档是影响软件可维护性的决定因素 • 软件再工程（预防性维护）
- 59. 59
Editor's Notes
- #32: 1. 可理解性 软件可理解性 诊断和测试的容易程度取决于软件容易理解的程度。良好的文档对诊断和测试是至关重要的，此外，软件结构、可用的测试工具和调试工具，以及以前设计的测试过程也都是非常重要的。维护人员应该能够得到在开发阶段用过的测试方案，以便进行回归测试。在设计阶段应该尽力把软件设计成容易测试和容易诊断的。 对于程序模块来说，可以用程序复杂度来度量它的可测试性。模块的环形复杂度越大，可执行的路径就越多，因此，全面测试它的难度就越高。 3. 可修改性 软件容易修改的程度和本书第 5 章讲过的设计原理和启发规则直接有关。耦合、内聚、信息隐藏、局部化、控制域与作用域的关系等等，都影响软件的可修改性。 4. 可移植性 软件可移植性指的是，把程序从一种计算环境（硬件配置和操作系统）转移到另一种计算环境的难易程度。把与硬件、操作系统以及其他外部设备有关的程序代码集中放到特定的程序模块中，可以把因环境变化而必须修改的程序局限在少数程序模块中，从而降低修改的难度。 5. 可重用性 所谓重用（ reuse ）是指同一事物不做修改或稍加改动就在不同环境中多次重复使用。大量使用可重用的软件构件来开发软件，可以从下述两个方面提高软件的可维护性： (1) 通常，可重用的软件构件在开发时经过很严格的测试，可靠性比较高，且在每次重用过程中都会发现并清除一些错误，随着时间推移，这样的构件将变成实质上无错误的。因此，软件中使用的可重用构件越多，软件的可靠性越高，改正性维护需求越少。 （ 2 ） 很容易修改可重用的软件构件使之再次应用在新环境中，因此，软件中使用的可重用构件越多，适应性和完善性维护也就越容易。
- #43: 1. 用户文档 用户文档是用户了解系统的第一步，它应该能使用户获得对系统的准确的初步印象。文档的结构方式应该使用户能够方便地根据需要阅读有关的内容。 用户文档至少应该包括下述 5 方面的内容： (1) 功能描述，说明系统能做什么； (2) 安装文档，说明怎样安装这个系统以及怎样使系统适应特定的硬件配置； (3) 使用手册，简要说明如何着手使用这个系统 ( 应该通过丰富例子说明怎样使用常用的系统功能，还应该说明用户操作错误时怎样恢复和重新启动 ) ； (4) 参考手册，详尽描述用户可以使用的所有系统设施以及它们的使用方法，还应该解释系统可能产生的各种出错信息的含义 ( 对参考手册最主要的要求是完整，因此通常使用形式化的描述技术 ) ； (5) 操作员指南 ( 如果需要有系统操作员的话 ) ，说明操作员应该如何处理使用中出现的各种情况。 上述内容可以分别作为独立的文档，也可以作为一个文档的不同分册，具体做法应该由系统规模决定。
- #50: 1. 库存目录分析 每个软件组织都应该保存其拥有的所有应用系统的库存目录。该目录包含关于每个应用系统的基本信息（例如，应用系统的名字，最初构建它的日期，已做过的实质性修改次数，过去 18 个月报告的错误，用户数量，安装它的机器数量，它的复杂程度，文档质量，整体可维护性等级，预期寿命，在未来 36 个月内的预期修改次数，业务重要程度等）。 应该仔细分析库存目录，按照业务重要程度、寿命、当前可维护性、预期的修改次数等标准，把库中的应用系统排序，从中选出再工程的候选者，然后明智地分配再工程所需要的资源。