第8章软件维护

改错或修改的要求不能及时满足引起的用户不满； 维护时的改动，引入潜伏错误，导致软件质量降低； 软件工程师从事维护工作造成的开发过程混乱。 生产率的大幅下降 维护工作量：生产性劳动+非生产性劳动。
分析评价，修改设计，编写代码等
理解代码功能、解释数据结构、接口特点和性能限度等
8.3 软件维护的特性
8.3.3 软件维护的副作用
-结构化维护
结构化维护是指软件开发过程是按照软件工程方法进 行的、各开发阶段文档齐全的软件的维护过程。
-非结构化维护
非结构化维护是指在只有源程序，缺乏必要的文档说 明，难于确定数据结构、系统接口等特性的情况下，进行 的软件维高昂
明显代价：高昂的维护费用，已上升达80%左右； 无形代价：
的工作环境，或适应已变动的数据或文件； （4）为预防软件系统的失效而对软件系统实施修改。
8.2 软件维护的分类
- 改正性维护
对在测试阶段未能发现的、在软件投入使用后才逐渐暴露出来的 错误的测试、诊断、定位、纠错，以及验证、修改的回归测试过程， 称为改正性维护。
- 完善性维护
为了满足用户在使用过程中对软件提出的新的功能与性能要求， 需要对原来的软件的功能进行修改或扩充。
- 适应性维护
使软件适应外部新的软硬件环境或者数据环境发生的变化， 而进行修改软件的过程。
- 预防性维护
为了提高软件未来的可维护性、可靠性等，或为了给未来 的改进奠定更好的基础而修改软件的过程。
8.2 软件维护的分类 预防性维护 4% 适应性维护 21% 完善性维护 50%
改正性维护 25%
四类维护占总维护的比例
修改软件设计、 复查、必要的代 码修改、单元测 试和集成测试、 验收测试和复审

(1) 必须描述如何使用这个系统，没有这种描述时即 使是最简单的系统也无法使用； (2) 必须描述怎样安装和管理这个系统； (3) 必须描述系统需求和设计； (4) 必须描述系统的实现和测试，以便使系统成为可 维护的。
用户文档
用户文档至少应该包括下述5方面的内容：
功能描述，说明系统能做什么； 安装文档，说明怎样安装这个系统以及怎样使系统
软件维护过程
维护报告
维护要求表或称软件问题报告表，由申请维 护的用户填写。
软件修改报告，由软件组织内部制定，指明：
满足某个维护要求表中提出的要求所需要的工 作量；
维护要求的性质； 这项要求的优先级； 与修改有关的事后数据；
维护的事件流
维护的事件流
尽管维护申请的类型不同，但都要进行同样 的技术工作：
系统文档
所谓系统文档指从问题定义、需求说明到验收 测试计划这样一系列和系统实现有关的文档。
描述系统设计、实现和测试的文档对于理解程 序和维护程序极端重要
从概貌到每个方面每个特点，从抽象到具体， 有逻辑地介绍系统
可维护性复审
在需求分析阶段的复审过程中，应该对将来要 改进的部分和可能会修改的部分加以注意并指 明；应该讨论软件的可移植性问题，并且考虑 可能影响软件维护的系统界面。
维护的问题
与软件维护有关的绝大多数问题，都可归 因于软件定义和软件开发的方法有缺点：
① 理解别人写的程序通常非常困难，而且困难程 度随着软件配置成分的减少而迅速增加。
② 需要维护的软件往往没有合格的文档，或者文 档资料显著不足。
③ 当要求对软件进行维护时，不能指望由开发人 员给我们仔细说明软件。
的。
软件维护工作量
各类维护工作量 所占比例
维护工作量在软件生 命周期所占比例

系统年龄： – 老系统随着不断的修改，结构越来越乱； – 维护人员经常更换，程序又变得越来越难于理解 – 许多老系统在当初并未按照软件工程的要求进行 开发，因而没有文档，或文档太少。 – 在长期的维护过程中文档在许多地方与程序实现 变得不一致，在维护时就会遇到很大困难。 数据库技术的应用：使用数据库，可以简单而有效 地管理和存储用户程序中的数据，还可以减少生成 用户报表应用软件的维护工作量。
24
8.4
软件的可维护性
许多软件的维护十分困难，原因在于这些软件 的文档不全、质量差、开发过程不注意采用好 的方法，忽视程序设计风格等。 许多维护要求并不是因为程序中出错而提出的， 而是为适应环境变化或需求变化而提出的。 为了使得软件能够易于维护，必须考虑使软件 具有可维护性。 软件可维护性是指纠正软件系统出现的错误和
14
1、维护机构 除了较大的软件开发公司外， 通常在软件维护工作方面，并 不保持一个正式的组织机构。 虽然不要求建立一个正式的维 护机构，但是在开发部门确立 一个非正式的维护机构则是非 常必要的。
15
每个维护要求都通过维护管理员转交给相应的系 统管理员去评价（系统管理员是被指定去熟悉一 小部分产品程序的技术人员）。 系统管理员对维护任务做出评价之后，由变化授 权人决定应该进行的活动。 16
缺陷，以及为满足新的要求进行修改、扩充或 压缩的难易程度。
25
8.4.1 决定软件可维护性的因素
1. 可理解性 2. 可测试性 3. 可修改性 4. 可移植性 5. 可重用性
26
1. 可理解性 软件可理解性表现为外来读者理解软件的结构、 功能、接口和内部处理过程的难易程度。模块化 （模块结构良好，高内聚，松耦合）、详细的设 计文档、结构化设计、程序内部的文档和良好的 高级程序设计语言等等，都对提高软件的可理解 性有重要贡献。 2. 可测试性 诊断和测试的容易程度取决于软件容易理解的程 度。良好的文档对诊断和测试是至关重要的，此 外，软件结构、可用的测试工具和调试工具，以 及以前设计的测试过程也都是非常重要的。维护 人员应该能够得到在开发阶段用过的测试方案， 以便进行回归测试。在设计阶段应该尽力把软件 设计成容易测试和容易诊断的。 对于程序模块来说，可以用程序复杂度来度量它 的可测试性。模块的环形复杂度越大，可执行的 路径就越多，因此，全面测试它的难度就越高。

33
5. 数据重构 对数据体系结构差的程序很难进行适应性和 完善性维护，因此，数据体系结构比源代码对程序 的长期生存力有更大影响。 数据重构是一种全范围的再工程活动。由于 数据重构对程序体系结构及程序中的算法有很大影 响，对数据的修改必然会导致程序体系结构或代码 层的改变。
3
2.适应性维护 为适应变化了的环境界面而修改软件的活动， 称为适应性维护。包括： （1）因硬件或支撑软件改变引起的变化； （2）将软件移植到新的机种上运行； （3）因数据环境的变化而做的变更。 这类维护大约占软件维护总工作量的25％。
4
3.完善性维护 为了满足用户要求，就得对软件进行修改和 扩充，我们称这种维护为完善性维护。完善性维护 主要包括： （1）提高处理效率； （2）提高性能。 在整个维护工作中， 完善性维护大约占50％ 左右，区居第一位。
3. 逆向工程 软件的逆向工程是，分析程序以便在比源代码 更高的抽象层次上创建出程序的某种描述的过程， 也就是说，逆向工程是一个恢复设计结果的过程。 4. 代码重构 某些老程序的体系结构比较合理，但是，一些 模块的编码方式却是难于理解、测试和维护的。在 这种情况下，可以重构这些模块的代码。 通常，代码重构并不修改程序的体系结构，它 只关注个体模块的设计细节以及在模块中定义的局 部数据结构。如果重构扩展到模块边界以外并涉及 软件体系结构，则重构变成了正向工程。
13
（四）软件维护过程 维护过程的实质是对软件定义和开发过程的修 改和压缩。维护过程的主要任务是：建立维护机构， 填写维护报告和评价，为每个维护要求规定一种规 范化的处理序列，建立对维护活动的登记制度及规 定评价复审的标准。 1.维护组织 机构中有一名维护管理员总负责，每项维护要 求都通过维护管理员转交给相应的系统管理员去评 价。系统管理员对维护任务做出评价之后，由变化 授权人决定应该进行的活动，最后由系统管理员去 执行维护任务。