软件维护

1. 软件维护 • 软件维护的概念 • 软件维护活动 • 程序修改的步骤及副作用 • 可维护性 • 提高可维护性的方法

2. 软件维护的定义 • SE:在软件运行(／维护)阶段对软件产品进行的修改就是维护软件Maintenance • In industry, maintenance means more than modification of software • 维护的类型有三种(按起因/目的分类) • 改正性维护 Corrective • 适应性维护 Adaptive • 完善性维护 Perfective

3. 改正性维护corrective • 在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。 • 这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。 • 识别和纠正软件错误而进行的诊断和改正错误的过程叫做改正性维护。

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

5. 完善性维护Perfective • 在软件的使用过程中，用户会对软件提出新的功能与性能要求。 • 为了满足这些要求，需要修改或再开发软件，为扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性而进行的维护叫做完善性维护。 • 预防Preventive＆进化Evolutive

6. 实践表明，在几种维护活动中，完善性维护所占的比重最大。约占整个维护工作的50％。即大部分维护工作是改变和加强软件，而不是纠错。实践表明，在几种维护活动中，完善性维护所占的比重最大。约占整个维护工作的50％。即大部分维护工作是改变和加强软件，而不是纠错。 • 完善性维护不应是救火式的紧急维修，而可以是有计划的再开发活动。

7. 三类维护占 总维护比例 维护在软件生 存期所占比例 Maintenance is also a source of benefice eg. new version sales

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

9. 系统年龄 • 老系统随着不断的修改，结构越来越乱 • 维护人员经常更换，程序又变得越来越难于理解。 • 许多老系统在当初并未按照软件工程的要求进行开发，因而没有文档，或文档太少。 • 在长期的维护过程中文档在许多地方与程序实现变得不一致，在维护时就会遇到很大困难。

10. 数据库技术的应用：使用数据库，可以简单而有效地管理和存储用户程序中的数据，还可以减少生成用户报表应用软件的维护工作量。数据库技术的应用：使用数据库，可以简单而有效地管理和存储用户程序中的数据，还可以减少生成用户报表应用软件的维护工作量。 • 先进的软件开发技术：在软件开发时，若使用能使软件结构比较稳定的分析与设计技术，及程序设计技术，如面向对象技术、复用技术等，可减少大量的工作量。

11. 其它影响维护工作量的因素： • 应用的类型 • 数学模型 • 任务的难度 • IF嵌套深度 • 许多软件在开发时并未考虑将来的修改，为软件的维护带来许多问题。

12. 软件维护的策略: • 最低总成本 • 开发考虑维护

13. 改正性维护通常要生成100％可靠的软件并不合算。平衡开发质量与成本可降低总成本. • 使用下列新技术，可减少改正性维护：数据库管理系统、软件开发环境、程序自动生成系统、较高级(第四代)的语言。以及新的开发方法、软件复用、防错程序设计及周期性维护审查等。

14. 适应性维护这类维护不可避免，可以控制。(1)把硬件、操作系统和其它相关环境因素的可能变化考虑在内。(2)把与硬件、操作系统，以及其它外围设备有关的程序归到特定的程序模块中。 (3)使用外部文件，以及处理的例行程序包，可为维护时修改程序提供方便。

15. 完善性维护利用前两类维护中列举的方法，也可以减少这一类维护。此外，建立软件系统的原型，把它在实际系统开发之前提供给用户。用户通过研究原型，进一步完善他们的功能要求，就可以减少以后完善性维护的需要。完善性维护利用前两类维护中列举的方法，也可以减少这一类维护。此外，建立软件系统的原型，把它在实际系统开发之前提供给用户。用户通过研究原型，进一步完善他们的功能要求，就可以减少以后完善性维护的需要。

16. 维护成本 • 有形的软件维护成本是花费了多少钱，无形的维护成本有更大的影响。 • 一些合理的修复或修改请求不能及时安排，使得客户不满意； • 变更的结果引入新的故障，使得软件整体质量下降； • 把软件人员抽调到维护工作中，干扰了软件开发工作。

17. 维护工作量的模型 • M是维护中消耗的总工作量 • p是生产性工作量 • K是一个经验常数 • c是因缺乏好的设计和文档而导致复杂性的度量 • d是对软件熟悉程度的度量。

18. 软件维护活动 • 为了有效地进行软件维护，应事先就做组织工作。 • 建立维护的机构 • 明确提出维护申请报告的过程及处理步骤 • 设立维护活动的登记制度以及规定评价和评审的标准。

19. 维护机构 • 除了较大的软件开发公司外，通常在软件维护工作方面，并不保持一个正式的组织机构。 • 开发部门确立一个非正式的维护机构则是必要的。每个角色要有负责人(不一定专职).

20. 软件维护的机构

21. 变更&配置管理 Change&Software Configuration Management • 软件工程过程中的软件变更必须严格加以控制和管理。 • 变更控制包括建立控制点和建立报告与审查制度。 • 配置管理为变更管理实施提供方法和工具 • 软件维护需要变更&配置管理

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

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

25. 软件维护工作流程

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

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

28. 维护档案记录 • 程序名称 • 源程序语句条数 • 机器代码指令条数 • 所用的程序设计语言 • 程序安装的日期 • 程序安装后的运行次数 • 与程序安装后运行次数有关的处理故障次数

29. 程序改变的层次及名称 • 修改程序增加的源程序语句条数 • 修改程序减少的源程序语句条数 • 每次修改所付出的“人时”数 • 修改程序的日期 • 软件维护人员的姓名 • 维护申请报告的名称、维护类型 • 维护开始时间和维护结束时间、 • 花费在维护上的累计“人时”数 • 维护工作的净收益等。

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

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

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

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

34. (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) 分析各个过程的接口，估计更改的复杂性。

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

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

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

38. 修改计划内容: 修改规格说明信息：数据、处理、系统之间接口等；  维护资源：新程序版本、测试数据、所需软件、计算机时间等； 人员: 参与者; 用料：耗材、计算机媒体等。

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

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

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

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

43. (1) 修改代码的副作用 • 在修改源代码时，都可能引入错误。例如，删除或修改一个子程序、删除或修改一个标号、 删除或修改一个标识符、改变程序代码的时序关系、改变占用存储的大小、改变逻辑运算符、修改文件的打开或关闭。

44. (2) 修改数据的副作用 • 在修改数据结构时，有可能造成软件设计与数据结构不匹配，因而导致软件出错。 • 数据副作用是修改软件信息结构导致的结果。 • 数据副作用可以通过交叉引用表加以控制。把数据元素、记录、文件和其它结构联系起来。

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

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

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

48. 计算机确认用计算机对修改程序进行确认测试：(1) 确认测试顺序：先对修改部分进行测试，然后再把它们与未修改部分集成起来进行测试。这种测试称为回归测试。 (2)准备标准的测试用例。(3) 充分利用软件工具帮助重新验证过程。 (4) 在重新确认过程中，应邀请用户参加。

49. 维护后的验收──在交付新软件之前，维护主管部门要检验：(1)全部文档是否完备，并已更新；(2)所有测试用例和测试结果已经正确记载；(3)软件配置包含所有新增和修改的文档, 测试用例和程序；(4)维护工序和责任已经确定。

50. 下堂课思考讨论题 • 1) 应用领域对维护工作量的影响: 举出适应性和完善性多与少的应用例子 • 2) 模块耦合度与可维护性 • 3) 面向对象的方法与可维护性 • 4) Your favorite topics about maintenance.