内容发布更新时间 : 2024/12/22 19:36:50星期一 下面是文章的全部内容请认真阅读。

第八章 维护

8.1 软件维护的定义

所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。

四类维护活动： 改正性维护 适应性维护

扩充与完善性维护 预防性维护

?改正性维护(corrective maintenance)

诊断和改正软件中存在的错误的活动。通常占整个维护活动的17-21%。

?适应性维护(adaptive maintenance)

为了和变化了的环境适当地配合而进行的修改软件的活动。通常占整个维护活动的18-25%。

?完善性维护(perfective maintenance)

为了满足用户在使用软件的过程中提出的增加新功能、修改已有功能或其它一般性改进的要求而进行的软件修改活动。通常占整个维护活动的50-66%。

?预防性维护(preventive maintenance)

为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件的活动。通常占整个维护活动的4%。

各类维护活动的根本目的是延长软件生存期 各类维护活动的根本目的是延长软件生存期

2个月-2年

软件 生存 周期

计 划 分 析 设 计 编 码 测 试 1年-10年

其它维护运行和维护(简称维护) 4 % 改善期 稳定期 陈旧期 重构

软件诞生

软件工程周期

常规软件生成周期时间的估计

8.2 维护的特点 ?非结构化维护

在软件配置的唯一成分只有程序代码的情况下所进行的维护 。

?结构化维护

在软件配置完整的情况下所进行的维护。 8.2.2 维护的成本 ?用于维护已有软件的费用占软件总预算的比例：

1970年为35-40%,1980年为40-60%,1990年为70-80%。

?其它无形的代价 ：

* 因为可用的资源必须供维护任务使用，以致耽误甚至丧失了开发新软件的良机。 * 当看来合理的有关错误修改或其他要求不能及时满足时将引起用户不满。 * 由于维护时的改动，在软件中引入了潜伏的故障，从而降低了软件的质量。 * 当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱。 8.2.3 影响维护工作量的因素 ?系统大小 ?程序设计语言 ?系统年龄

?数据库技术的应用 ?先进的软件开发技术 ?其它

8.2.4 维护中的典型问题

(1)难以跟踪软件版本的进化过程,软件的变化未在文档中反映出来. (2)难以跟踪软件的创建过程. (3)难以读懂他人程序. (4)无文档或文档不全. (5)软件人员流动性大.

(6)设计时未考虑修改需要,修改困难. (7)维护工作无吸引力,缺乏成就感.

8.2.5 维护的副作用(side effects) ?由于维护或在维护过程中其它一些不期望的行为引入的错误 ，称为维护的副作用。 ?共分三类

代码副作用（引入新的错误）

数据副作用（破坏数据完整性、规范性） 文档副作用（文档与实际系统的同步更新） 8.3 软件维护过程 8.3.1维护组织 维护 管理员 系统 管理员 （把关） 配置管理员 修改 负责人 维护人员 （接受维护申请） （评价） （确定方案） （修改）

8.3.2 软件维护申请报告 ?维护申请报告(MRR，Maintenance Request Report)，或称软件问题表(SPF，Software Problem Form)，由申请维护的用户填写。

?软件修改报告(SCR，Software Change Report)，由软件组织内部提供。 –所需修改变动的性质 - 为满足某个MRR所需工作量 –申请修改的优先级 - 预计修改后的状况 8.3.3 维护工作流程

改正性维护 严重错误 非严重错误 用户请求维护 确定维护类型 高优先级 适应性 完善性 预防性维护 派人调查分析-提出修改方案-修改-测试 列入日常维护计划 低优先级

不管维护类型如何，都需要进行同样的技术工作，包括： 修改软件设计； 复查；

必要的代码修改； 单元测试；

集成测试（包括回归测试）； 验收测试； 复审。

#为了估计软件维护的有效程度，确定软件产品的质量，同时确定维护的实际开销，需要在维护的过程中做好维护档案记录。

#维护档案记录主要内容包括程序名称、所用的程序设计语言、程序安装的日期、修改程序所增加/减少的源程序语句条数、修改程序的日期、软件维护人员的姓名、维护申请报告的名称、维护类型、维护开始时间和维护结束时间、花费在维护上的累计“人时”数、维护工作的净收益等等。 8.4 软件可维护性

8.4.1 软件可维护性的定义

软件可维护性是指维护人员理解、改正、改动和改进这个软件的难易程度。

?提高可维护性是支配软件工程方法论所有步骤地关键目标。 ?衡量软件质量的几个主要质量特性：

可维护性 可使用性 可靠性

?决定软件可维护性的因素：

可理解性 可测试性 可修改性 可移植性 可重用性 可理解性

软件可理解性表明人们通过阅读源代码和相关文档，了解软件功能及其如何运行的（外来读者理解软件的结构、接口、功能和内部过程的）难易程度。 可测试性

可测试性表明了论证程序正确性的容易程度。程序越简单，证明其正确性就越容易。

可修改性

可修改性表明程序容易修改的程度。一个可修改的程序应当是可理解的、通用的、灵活的、简单的。 可移植性

软件可移植性指的是，把程序从一种环境转移到另一种计算环境的难易程度。 可重用性

可重用性是指同一事物不做修改或稍加改动就可在不同环境中重复使用。 可移植性

8.4.2 提高可维护性的方法

? 建立明确的软件质量目标和优先级

? 使用提高软件质量的技术和工具 ? 进行明确的质量保证审查 ? 选择可维护的程序设计语言 ? 改进程序的文档

? 开发软件时考虑到维护

8.4.3 可维护性复审 ?在软件工程过程的每一个阶段都应该考虑并努力提高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。

?需求分析阶段的复审中，应该对将来要改进的部分和可能会修改的部分加以注意并指明；应该讨论软件的可移植性问题，并且考虑可能影响软件维护的系统界面。

?在设计复审期间，应该从容易修改、模块化和功能独立的目标出发，评价软件的结构和过程；设计中应该对将来可能修改的部分预做准备。

– 代码复审应该强调编码风格和内部说明文档这两个影响可维护性的重要因素。

– 每个测试步骤都可以暗示在软件正式交付使用前，程序中可能需要做预防性维护的部分。

– 测试结束时进行最正式的可维护性复审，这个复审称为配置复审。配置复审的目的是保证软件配置的所有成分是完整的、一致的和可理解的。

?注意：

1、在完成了每项维护工作之后，都应该对软件维护本身进行仔细认真的复审。 2、维护应该针对整个软件配置，不应该只修改源程序代码。 8.5 逆向工程与再工程 ?逆向工程与再工程（重构工程）是目前预防性维护采用的主要技术。

?软件的逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序表示的过程。逆向工程也是设计恢复的过程。 ?逆向工程不同于反编译。 ?再工程（重构工程），是指在逆向工程所获取信息的基础上修改或重构已有的系统，产生系统的一个新版本，从而改进其整体质量。

8.5.1 预防性维护

预防性维护方法是由Miller提出的。他的想法是“结构化翻新”，并将其定义为： 把今天的方法用于昨天的系统，以支持明天的需要。

为何进行预防性维护：

1）维护一行源代码的代价可能14-40倍于初始开发该行源代码的代价；

2) 软件体系结构的重新设计使用了现代设计概念，它对将来的维护可能有很大的帮助； 3) 由于软件的原型已经存在，开发生产率应当大大高于平均水平；

4) 现行用户具有较多该软件的使用经验，新的变更需求和变更的范围能够较容易地搞清； 5) 逆向工程和重构工程的工具可以使一部分工作自动化； 6) 软件配置将可以在完成预防性维护的基础上建立起来。 8.5.2 逆向工程

?逆向工程就好象一个魔术管道，把一个非结构化的源代码清单填入管道，从管道的另一端

出来计算机软件的全部文档。也就是说，逆向工程可以从源代码中提取设计信息。 修改程序(无相应文档)，可以有以下几种选择

1)通过反复修改，与不可见的设计及源代码“战斗”，以实现必要的变更； 2)尽可能多地掌握程序的内部工作细节，以便更有效地做出修改； 3)重新设计、编码和测试那些需要变更的软件部分，把软件工程方法应用于所有修改的部分； 4)对程序全部重新设计、编码和测试，可以选用CASE(Computer-Aided Software Engineering)工具(逆向工程和重构工程工具)来帮助掌握原有的设计。

逆向工程示意

概要设计

源程序

详细设计

需求分析

目标代码 源程序 概要设计

8.5.3 重构工程

?重构组合了逆向工程的分析和设计抽象的特点，具有对程序数据、体系结构和逻辑的重构

能力。

?执行重构可生成一个设计，它产生与原来程序相同的功能，但质量比原来的高。

作业

8-1软件维护活动可分为哪四种类型？各有什么特点？ 8-2习题八－1。