软件维护

1. 软件维护 • 软件维护的分类 • 维护过程和维护活动 • 维护的副作用 • 可维护性 • 逆向工程和再工程

2. 软件维护阶段覆盖了从软件交付使用到软件被淘汰为止的整个时期。开发一个软件可能需要一、二年，甚至更短，但它的使用时间可能要几年或几十年。在整个使用期都可能需要维护，所以维护的代价是很大的，而且还在逐年上升。因此如何提高软件维护的效率，降低维护的代价已成为十分重要的问题。软件维护阶段覆盖了从软件交付使用到软件被淘汰为止的整个时期。开发一个软件可能需要一、二年，甚至更短，但它的使用时间可能要几年或几十年。在整个使用期都可能需要维护，所以维护的代价是很大的，而且还在逐年上升。因此如何提高软件维护的效率，降低维护的代价已成为十分重要的问题。 现代的软件工程要求软件维护覆盖软件的整个生存周期，即在分析、设计、编码等阶段都要考虑软件的可维护性，以减少软件维护的代价。

3. 软件维护 • 软件维护的分类 • 维护过程和维护活动 • 维护的副作用 • 可维护性 • 逆向工程和再工程

4. 软件维护的分类 软件维护的类型有四种： • 改正性维护（corrective） • 适应性维护（adaptive） • 完善性维护（perfective） • 预防性维护（preventive）

5. 改正性维护 • 即使有最好的质量保证机制，在软件交付使用后，软件中必然存在某些隐藏的错误。这些隐藏的错误在某些特定的使用环境下就会暴露出来。 • 改正性维护是指：为了改正隐藏错误而修改软件的活动。 • 改正性维护也称纠错性维护。

6. 适应性维护 • 在使用过程中，随着时间的推移，原来的软件开发环境（如CPU、操作系统、商业规则、外部产品特征）可能发生变化。 • 适应性维护是指：为适应外部环境的变化而修改软件的活动。

7. 完善性维护 • 在软件的使用过程中，用户往往会对软件提出新的功能要求。 • 完善性维护是指：为了扩展原来的功能需求而修改软件的活动。

8. 预防性维护 • 计算机软件由于修改而逐渐退化，因此，预防性维护（常常称为软件再工程—software reengineering）必须旨在使软件满足其最终用户的要求。 • 本质上讲，预防性维护修改计算机程序使得它们能够被更好地纠错、适应和增强。

9. 另一种说法是：预防性维护是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础而修改软件的活动。另一种说法是：预防性维护是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础而修改软件的活动。

10. 维护在软件生 存期所占的比例 各类维护占总维护的比例

11. 软件维护 • 软件维护的分类 • 维护过程和维护活动 • 维护的副作用 • 可维护性 • 逆向工程和再工程

12. 阅读设计 重新编码 重新编码 结构化与非结构化维护

13. 维护成本 • 有形的软件维护成本：维护的费用（耗费的人力、财力等），其它，如由于资源优先用于维护任务，影响新软件的开发，可能会丧失良机。 • 无形的维护成本：例如 • 某些貌似合理但实际不能满足的维护请求将引起用户的不满； • 在软件维护过程中引入的潜在错误降低了软件的质量； • 从开发小组临时抽调工程师从事维护工作冲击了正在进行的开发；等。

14. 维护旧的程序使生产率大幅度下降。 例如，开发一行源代码的成本为25美元，但维护一行源代码的成本可达到1000美元，生产率下降了40倍。 • 软件维护工作量可分为： • 生产性工作量：如分析和评价，修改设计和编码等 • 非生产性工作量：如理解代码功能，解释数据结构、接口特性、性能约束等）。

15. 维护工作量的估算模型 其中： M是维护所用的总工作量 p是生产性工作量 K是一个经验常数 c是复杂度，标志设计的好坏和文档的完整程度 d是对欲维护软件的熟悉程度

16. 模型指明，如果未使用好的软件开发方法（即未遵循软件工程的思想）或原来的软件开发人员不能参与维护，则工作量（及成本）将按指数级增加。模型指明，如果未使用好的软件开发方法（即未遵循软件工程的思想）或原来的软件开发人员不能参与维护，则工作量（及成本）将按指数级增加。

17. 软件维护中可能存在的问题 • 与维护有关的典型问题： • 很难甚至不可能追踪软件版本的进化过程，软件的变化未在响应的文档中反映出来； • 很难甚至不可能追踪软件的整个创建过程； • 理解他人的程序非常困难，当软件配置不全，仅有源代码时尤为严重； • 软件人员流动性很大，维护他人软件时很难得到开发者的支持；

18. 软件没有文档、或文档不全、或文档不易理解、或文档与源代码不一致；软件没有文档、或文档不全、或文档不易理解、或文档与源代码不一致； • 多数软件设计未考虑修改的需要，使得软件修改不仅困难而且容易出错； • 软件维护不是一项有吸引力的工作，从事这项工作令人缺乏成就感。

19. 软件维护活动 • 维护组织 • 维护申请报告及评估 • 维护活动的事件流 • 保存维护记录 • 评价维护活动

20. 维护组织 • 除了较大的软件开发公司外，通常在软件维护工作方面，并不保持一个正式的组织机构。 • 虽然不要求建立一个正式的维护机构，但是在开发部门确立一个非正式的定岗定职也是非常必要的。

21. 系统管理员 软件维护的组织模式

22. 维护申请提交给维护管理员，他把申请转交给某个系统管理员（系统主管）。维护申请提交给维护管理员，他把申请转交给某个系统管理员（系统主管）。 • 系统主管一般都是对程序（某一部分）特别熟悉的技术人员，他们对维护申请及可能引起的软件修改进行评估，并向修改控制决策机构报告，由他最后确定是否采取行动。 • 维护人员负责对程序进行修改。 • 配置管理员进行把关，控制修改的范围，对软件配置进行审计。 • 这种组织方式能减少维护过程的混乱和盲目性，避免因小失大的情况发生。

23. 维护申请报告与评估 • 维护申请报告应采用标准化的格式，如维护申请表或软件问题报告，它们由申请维护的用户填写。 • 对改正性维护，用户必须必须完整地说明出错现场的信息，包括输入数据、错误清单以及其它有关材料。 • 对适应性维护或完善性维护，用户必须提出一份简短的修改规格说明书（需求规格说明）。

24. 维护申请被批准后，维护申请报告就成为外部文档，作为本次维护的依据。维护申请被批准后，维护申请报告就成为外部文档，作为本次维护的依据。 • 还应制订一个软件修改报告，指明： • 为满足维护申请报告提出的需求所需的工作量； • 本次维护活动的性质； • 本次维护请求的优先级； • 本次修改的背景数据。 • 软件修改报告提交给修改控制决策机构，供进一步规划维护活动使用。

25. 软件维护工作流程

26. 尽管维护申请的类型不同，但都要进行同样的一系列技术工作：尽管维护申请的类型不同，但都要进行同样的一系列技术工作： • 修改软件需求说明 • 修改软件设计 • 设计评审 • 必要时重新编码 • 单元测试 • 集成测试( 包括回归测试) • 确认测试 • 软件配置评审等。

27. 在每次软件维护任务完成后进行状况评审（ situation review ），主要考虑以下问题：(1)在当前状况下，设计、编码、测试的哪些方面能用不同的方法进行?(2)哪些维护资源应该有但没有?(3)这次维护活动中主要的或次要的障碍是什么?(4)在维护请求中有预防性维护吗? • 状况评审的目的是促进未来的维护工作，同时也为有效管理软件组织提供重要的反馈信息。

28. 保存维护记录 记录的内容： • 程序名称 • 源代码行数 • 机器代码指令条数 • 所用的程序设计语言 • 程序安装的日期 • 程序安装后的运行次数 • 与程序安装后程序失效的次数

29. 程序修改处的层次及名称 • 因修改程序而增加的源程序行数 • 因修改程序而删除的源程序行数 • 每次修改所耗费的“人时”数 • 修改程序的日期 • 软件维护人员的姓名 • 维护申请报告的名称、维护类型 • 维护开始日期和维护结束日期 • 花费在维护上的累计“人时”数 • 维护工作的净收益等

30. 评价维护活动 • 评价维护活动比较困难，需要一些有关维护“性能”方面的度量数据。 • 有关维护“性能”方面的度量数据： • 每次程序运行时的平均失效次数； • 花费在每类维护上的总“人时”数； • 每个程序、每种语言、每种维护类型的程序平均修改次数； • 因为维护，增加或删除每个源程序语句所花费的平均“人时”数；

31. 维护每种语言的程序平均花费的“人时”数； • 一份维护申请报告的平均处理时间； • 各类维护请求的百分比。 • 据此可对开发技术、编程语言、维护工作量的预测、资源分配、以及其它许多方面的决策进行评价。

32. 软件维护 • 软件维护的分类 • 维护过程和维护活动 • 维护的副作用 • 可维护性 • 逆向工程和再工程

33. 维护的副作用 • 维护的副作用指在维护过程中，因修改软件而引起的错误或其它不希望发生的行为。 • 维护的副作用大致可分为三类： • 代码副作用 • 数据副作用 • 文档副作用

34. (1)修改代码的副作用 • 每次代码修改都可能引入潜在的错误。下列修改更易出错： • 删除或修改一个子程序 • 删除或修改一个标号 • 删除或修改一个标识符 • 为提高程序的执行效率而做的修改 • 修改文件的打开或关闭操作 • 修改逻辑运算符 • 由设计修改引起的代码修改 • 修改边界条件

35. 代码副作用可以通过回归测试发现，此时应立即采取补救措施。代码副作用可以通过回归测试发现，此时应立即采取补救措施。

36. (2) 修改数据的副作用 • 容易引起数据副作用的修改有： • 重新定义局部的或全局的常量 • 重新定义记录或文件的格式 • 增大或减小一个数组或其它复杂数据结构的体积 • 修改全局或公共数据 • 重新初始化控制标志或指针 • 重新排列输入／输出表或子程序的参数表

37. 数据副作用可以通过交叉访问表加以控制。交叉访问表把数据与引用它们的模块一一对应起来。数据副作用可以通过交叉访问表加以控制。交叉访问表把数据与引用它们的模块一一对应起来。

38. (3) 文档的副作用 • 维护时应考虑整个软件配置，在修改源程序的同时应及时修改相应的文档。如果文档未能准确反映代码的修改情况就导致文档副作用。 • 若使用手册未反映修改后的状况，那么用户在这些问题上必定会出错。 • 一次维护完成后，再次交付前应仔细复审整个配置，这可有效地较少文档副作用。

39. 软件维护 • 软件维护的分类 • 维护过程和维护活动 • 维护的副作用 • 可维护性 • 逆向工程和再工程

40. 可维护性（maintainability） • 软件可维护性是指理解、改正、调整和改进软件的难易程度。 • 影响可维护性的因素主要有： • 可理解性（understandability） • 可测试性（testability） • 可修改性（modifiability） • 可移植性（portability）

41. 可理解性 • 可理解性是指理解软件的结构、接口、功能和内部过程的难易程度。 • 提高软件可理解性的措施有：采用模块化的程序结构；书写详细正确的文档；采用结构化程序设计；书写源程序的内部文档；使用良好的编程语言；具有良好的程序设计风格等。

42. 可测试性 • 可测试性是指测试和诊断软件（主要指程序）中错误的难易程度。 • 提高软件可测试性的措施有：采用良好的程序结构；书写详细正确的文档；使用测试工具和调试工具；保存以前的测试过程和测试用例等。

43. 可修改性 • 可修改性是指修改软件（主要指程序）的难易程度。 • 在修改软件时经常会发生这样的情况：修改了程序中某个错误的同时又产生新的错误（由程序的修改引起的）；或者在程序中增加了某个功能后，导致原先的某些功能不能正常执行。这主要是因为程序中各成分之间存在着许多联系，当程序中某处修改时，这些修改可能会影响到程序的其它部分。

44. 如果一个程序的某个修改，其影响波及的范围越大，则该程序的可修改性就越差；反之，其可修改性越好。如果一个程序的某个修改，其影响波及的范围越大，则该程序的可修改性就越差；反之，其可修改性越好。 • 软件设计中介绍的设计准则和启发式规则都是影响可修改性的因素。

45. 可移植性 • 可移植性是指程序转移到一个新的计算环境的难易程度。 • 影响软件可移植性的因素有：信息隐蔽原则；模块独立；模块化；高内聚低耦合；良好的程序结构；不用标准文本以外的语句等。

46. 若干量化的度量 • 软件可维护性很难定量度量。然而，借助维护活动中可以定量测量的属性能间接度量可维护性。 • 察觉到问题所耗费的时间 • 收集维护工具所用的时间 • 分析问题所需的时间 • 形成修改说明书所需的时间

47. 纠错或修改所用的时间 • 局部测试所用的时间 • 整体测试所用的时间 • 维护复审所用的时间 • 完全恢复所用的时间

48. 保证可维护性的评审 • 在软件工程每一阶段的评审中，可维护性都是重要的审查指标。 • 需求分析评审：对将来可能修改和可以改进的部分加以注解，对软件的可移植性加以讨论，并考虑可能影响软件维护的系统接口。 • 设计评审：从易于维护和提高设计总体质量的角度全面评审数据设计、总体结构设计、过程设计和界面设计。

49. 代码评审：强调编程风格和内部文档。 • 测试时应指出软件正式交付前应进行的预防性维护。 • 维护活动完成后也要进行评审。

50. 软件维护 • 软件维护的分类 • 维护过程和维护活动 • 维护的副作用 • 可维护性 • 逆向工程和再工程