软件工程概论6-软件维护课件.ppt

1、2023-1-261/66软件工程导论 第第8章章 维护维护n 软件交付后，就进入维护期，这是软件生命周期的最软件交付后，就进入维护期，这是软件生命周期的最后一个阶段，基本任务是保证软件正常运行后一个阶段，基本任务是保证软件正常运行;n 维护需要的工作量很大、投入也大维护需要的工作量很大、投入也大;n对大型软件，是开发成本的对大型软件，是开发成本的4 4倍左右，主要包括运倍左右，主要包括运行成本和维护成本；行成本和维护成本；n国外许多软件开发组织把国外许多软件开发组织把60%60%以上的人力用于维护以上的人力用于维护已有的软件，这个百分比还在持续上升已有的软件，这个百分比还在持续上升n 软件工

2、程的目标之一，就是要提高软件的可维护性，软件工程的目标之一，就是要提高软件的可维护性，减少软件维护成本。减少软件维护成本。2023-1-262/66软件工程导论 第第8章章 维护维护8.1 8.1 软件维护的内容软件维护的内容8.2 8.2 维护的特点维护的特点8.3 8.3 维护任务的实施维护任务的实施8.4 8.4 软件的可维护性软件的可维护性2023-1-263/66软件工程导论 n为了改正错误或满足新的需要而修改软件的过程，为了改正错误或满足新的需要而修改软件的过程，即是软件维护即是软件维护n维护的内容包括四种：维护的内容包括四种：改正性维护（改正性维护（21%21%）适应性维护（适应

3、性维护（25%25%）完善性维护（完善性维护（50%50%）预防性维护（预防性维护（4%4%）8.1 8.1 软件维护的内容软件维护的内容2023-1-264/66软件工程导论 改正性维护改正性维护v由维护人员诊断和改正错误的过程，称为改正由维护人员诊断和改正错误的过程，称为改正性维护。性维护。v因为测试的不彻底性和测试的不可能穷举，必因为测试的不彻底性和测试的不可能穷举，必然有些隐错，在某些特定应用环境下，必然会然有些隐错，在某些特定应用环境下，必然会暴露出来；暴露出来；v发现错误，极时改正，由维护人员进行发现错误，极时改正，由维护人员进行2023-1-265/66软件工程导论 适应性维护适

4、应性维护n 硬件换代、操作系统升级速度非常快，而应用硬件换代、操作系统升级速度非常快，而应用软件的使用寿命却可能很长，远长于最初开发软件的使用寿命却可能很长，远长于最初开发这个软件时的运行环境的寿命这个软件时的运行环境的寿命;n 适应性维护，也就是为了使软件与变化了的环适应性维护，也就是为了使软件与变化了的环境适应而进行的修改境适应而进行的修改2023-1-266/66软件工程导论 完善性维护完善性维护l 使用过程中，用户会提出增新功能或修改已有使用过程中，用户会提出增新功能或修改已有功能的要求，或者是提出一般性的改进意见。功能的要求，或者是提出一般性的改进意见。l 为了满足这类要求，需要对软

5、件进行为了满足这类要求，需要对软件进行完善性维完善性维护护。l 这项维护活动通常占软件维护工作的量最大（这项维护活动通常占软件维护工作的量最大（50%50%）2023-1-267/66软件工程导论 预防性维护预防性维护n 当为了改善软件的可维护性或可靠性，或为了当为了改善软件的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件时，给未来的改进奠定更好的基础而修改软件时，出现了第四项维护活动。这项维护活动通常称出现了第四项维护活动。这项维护活动通常称为预防性维护；为预防性维护；n 目前这项维护活动相对比较少。目前这项维护活动相对比较少。2023-1-268/66软件工程导论 小结小结n

6、 从上述关于软件维护的定义不难看出，软件维护绝不从上述关于软件维护的定义不难看出，软件维护绝不仅限于纠正错误，事实上一半以上是完善性维护仅限于纠正错误，事实上一半以上是完善性维护;n 国外的统计数字表明国外的统计数字表明:n完善性维护占完善性维护占50%50%66%66%；n改正性维护占改正性维护占17%17%21%21%；n适应性维护占适应性维护占18%18%25%25%；n其他维护活动只占其他维护活动只占4%4%左右。左右。n 应该注意，上述应该注意，上述4 4类维护活动都必须应用于整个软件配类维护活动都必须应用于整个软件配置，维护软件文档和维护软件的可执行代码是同样重置，维护软件文档和维

7、护软件的可执行代码是同样重要的。要的。2023-1-269/66软件工程导论 第第8章章 维护维护8.1 8.1 软件维护的内容软件维护的内容8.2 8.2 维护的特点维护的特点8.3 8.3 维护任务的实施维护任务的实施8.4 8.4 软件的可维护性软件的可维护性2023-1-2610/66软件工程导论 8.2 8.2 软件维护的特点软件维护的特点8.2.1 8.2.1 非结构化维护与结构化维护非结构化维护与结构化维护8.2.2 8.2.2 维护的困难性维护的困难性8.2.3 8.2.3 维护的费用维护的费用2023-1-2611/66软件工程导论 8.2.1 8.2.1 非结构化维护与结构

8、化维护非结构化维护与结构化维护v非结构化维护与结构化维护差别很大，维护的非结构化维护与结构化维护差别很大，维护的困难也不同困难也不同2023-1-2612/66软件工程导论 1.1.非结构化维护非结构化维护n 如果软件配置只有程序代码，没有或很少有文档，就如果软件配置只有程序代码，没有或很少有文档，就是非结构化维护，维护活动将非常艰难；是非结构化维护，维护活动将非常艰难；n 首先难在维护必须从阅读、理解源代码开始；首先难在维护必须从阅读、理解源代码开始；n 其次，对于软件结构、数据结构、系统接口、性能和其次，对于软件结构、数据结构、系统接口、性能和设计约束等经常会产生误解，而且对程序代码所做的

9、设计约束等经常会产生误解，而且对程序代码所做的改动的后果也是难于估量的；改动的后果也是难于估量的；n 第三，因为没有测试方面的文档，所以不可能进行回第三，因为没有测试方面的文档，所以不可能进行回归测试归测试n 非结构化维护需要付出很大代价非结构化维护需要付出很大代价(浪费精力并且遭受挫浪费精力并且遭受挫折的打击折的打击)，这种维护方式是没有使用良好定义的方法，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。学开发出来的软件的必然结果。2023-1-2613/66软件工程导论 2.2.结构化维护结构化维护v 结构化维护是有据、有序地进行的结构化维护是有据、有序地进行的v 如果有完

10、整的软件配置，维护工作就可以从评价设计文档如果有完整的软件配置，维护工作就可以从评价设计文档开始，开始，u（1 1）确定软件重要的结构特点、性能特点以及接口特点；）确定软件重要的结构特点、性能特点以及接口特点；u（2 2）估量要求的改动将带来的影响，并且计划实施途径。）估量要求的改动将带来的影响，并且计划实施途径。v 然后，然后，u（1 1）首先修改设计并且对所做的修改进行仔细复查。）首先修改设计并且对所做的修改进行仔细复查。u（2 2）接下来编写相应的源程序代码；）接下来编写相应的源程序代码；u（3 3）使用在测试说明书中包含的信息进行回归测试；）使用在测试说明书中包含的信息进行回归测试；u

11、（4 4）最后，把修改后的软件再次交付使用。）最后，把修改后的软件再次交付使用。2023-1-2614/66软件工程导论 n 上面描述的事件，就所谓的结构化维护，它是在软件上面描述的事件，就所谓的结构化维护，它是在软件开发的早期应用软件工程方法学的结果。开发的早期应用软件工程方法学的结果。n 虽然有了软件的完整配置并不能保证维护中没有问题虽然有了软件的完整配置并不能保证维护中没有问题，但是确实能减少精力的浪费并且能提高维护的总体，但是确实能减少精力的浪费并且能提高维护的总体质量。质量。2023-1-2615/66软件工程导论 8.2 8.2 软件维护的特点软件维护的特点8.2.1 8.2.1

12、非结构化维护与结构化维护非结构化维护与结构化维护8.2.2 8.2.2 维护的困难性维护的困难性8.2.3 8.2.3 维护的费用维护的费用2023-1-2616/66软件工程导论 8.2.2 8.2.2 维护的困难性维护的困难性n 与软件维护有关的绝大多数问题，都可归因于与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺限。软件定义和软件开发的方法有缺限。n 在软件生命周期的头两个时期没有严格而又科在软件生命周期的头两个时期没有严格而又科学的管理和规划，几乎必然会导致在最后阶段学的管理和规划，几乎必然会导致在最后阶段出现问题。出现问题。n 维护困难主要表现如下：维护困难主要

13、表现如下：2023-1-2617/66软件工程导论 读懂别人的程序是困难的读懂别人的程序是困难的v理解别人写的程序通常非常困难，且困难程度理解别人写的程序通常非常困难，且困难程度随着软件配置成分的减少而迅速增加。随着软件配置成分的减少而迅速增加。v如果仅有程序代码没有说明文档，则会出现严如果仅有程序代码没有说明文档，则会出现严重的问题。重的问题。2023-1-2618/66软件工程导论 文档的不一致性文档的不一致性v 需要维护的软件往往没有合格的文档，或者需要维护的软件往往没有合格的文档，或者文档资料显著不足、内容与软件不一致。文档资料显著不足、内容与软件不一致。v认识到软件必须有文档仅仅是第

14、一步，容易理认识到软件必须有文档仅仅是第一步，容易理解的并且和程序代码完全一致的文档才真正有解的并且和程序代码完全一致的文档才真正有价值的。价值的。2023-1-2619/66软件工程导论 维护人员不可能总是开发人员维护人员不可能总是开发人员v当要求对软件进行维护时，不能指望由开发人当要求对软件进行维护时，不能指望由开发人员给我们仔细说明软件。员给我们仔细说明软件。由于维护阶段持续的时间很长，因此，当需要由于维护阶段持续的时间很长，因此，当需要解释软件时，往往原来写程序的人已经不在附解释软件时，往往原来写程序的人已经不在附近了。近了。2023-1-2620/66软件工程导论 软件设计时没有很好

15、的考虑可维护性软件设计时没有很好的考虑可维护性v 绝大多数软件在设计时没有考虑将来的修改绝大多数软件在设计时没有考虑将来的修改问题。问题。v除非使用强调模块独立原理的设计方法学，否除非使用强调模块独立原理的设计方法学，否则修改软件既困难又容易发生差错。则修改软件既困难又容易发生差错。2023-1-2621/66软件工程导论 软件维护不是一项吸引人的工作软件维护不是一项吸引人的工作v形成这种观念很大程度上是因为维护工作经常形成这种观念很大程度上是因为维护工作经常遭受挫折。遭受挫折。2023-1-2622/66软件工程导论 8.2.2 8.2.2 维护的困难性维护的困难性v读懂别人的程序是困难的读

16、懂别人的程序是困难的v文档的不一致性文档的不一致性v维护人员不可能总是开发人员维护人员不可能总是开发人员v软件设计时没有很好的考虑可维护性软件设计时没有很好的考虑可维护性v软件维护不是一项吸引人的工作软件维护不是一项吸引人的工作2023-1-2623/66软件工程导论 8.2 8.2 软件维护的特点软件维护的特点8.2.1 8.2.1 非结构化维护与结构化维护非结构化维护与结构化维护8.2.2 8.2.2 维护的困难性维护的困难性8.2.3 8.2.3 维护的费用维护的费用2023-1-2624/66软件工程导论 8.2.3 8.2.3 维护的费用维护的费用n 在过去的几十年中，软件维护的费用

17、逐年上升在过去的几十年中，软件维护的费用逐年上升n 用于维护已有软件的费用只占软件总预算：用于维护已有软件的费用只占软件总预算：n 19701970年：年：35%35%40%40%；n 19801980年：年：40%40%60%60%；n 19901990年：年：70%70%80%80%。2023-1-2625/66软件工程导论 其他无形的代价还有：其他无形的代价还有：n 当看来合理的有关改错或修改的要求不能及时当看来合理的有关改错或修改的要求不能及时满足时将引起用户不满；满足时将引起用户不满；n 由于维护时的改动，在软件中引入了潜伏的错由于维护时的改动，在软件中引入了潜伏的错误，从而降低了软

18、件的质量；误，从而降低了软件的质量；n 当必须把软件工程师调去从事维护工作时，将当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱。在开发过程中造成混乱。n 软件维护的最后一个代价是生产率的大幅度下软件维护的最后一个代价是生产率的大幅度下降，这种情况在维护旧程序时常常遇到。降，这种情况在维护旧程序时常常遇到。2023-1-2626/66软件工程导论 关于维护活动及工作量估算关于维护活动及工作量估算n 用于软件维护工作的活动可以分为：生产性活用于软件维护工作的活动可以分为：生产性活动和非生间性活动；动和非生间性活动；n 生产生活动，例如，分析评价，修改设计和编生产生活动，例如，分析评价

19、，修改设计和编码等码等n 非生产性活动，例如，理解程序代码的功能，非生产性活动，例如，理解程序代码的功能，解释数据结构、接口特点和性能限制等。解释数据结构、接口特点和性能限制等。2023-1-2627/66软件工程导论 工作量估算：工作量估算：n 维护工作量估计模型：维护工作量估计模型：M=M=P+KP+Kexp(c-dexp(c-d)n 其中：其中：nM M是维护用的总工作量，是维护用的总工作量，nP P是生产性工作量，是生产性工作量，nK K是经验常数，是经验常数，nc c是复杂程度是复杂程度(非结构化设计和缺少文档都会增加软件的复非结构化设计和缺少文档都会增加软件的复杂程度杂程度)，nd

20、 d是维护人员对软件的熟悉程度。是维护人员对软件的熟悉程度。n 上面的模型表明，如果软件的开发途径不好上面的模型表明，如果软件的开发途径不好(即，没有即，没有使用好的软件工程方法使用好的软件工程方法)，而且原来的开发人员不能参，而且原来的开发人员不能参加维护工作，那么维护工作量和费用将指数地增加。加维护工作，那么维护工作量和费用将指数地增加。2023-1-2628/66软件工程导论 第第8章章 维护维护8.1 8.1 软件维护的内容软件维护的内容8.2 8.2 维护的特点维护的特点8.3 8.3 维护任务的实施维护任务的实施8.4 8.4 软件的可维护性软件的可维护性2023-1-2629/6

21、6软件工程导论 8.3 8.3 维护任务的实施维护任务的实施v 维护过程本质上是缩减了的软件定义和开发过程，而维护过程本质上是缩减了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件维护有且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了关的工作已经开始了v 首先必须建立一个维护组织；首先必须建立一个维护组织；v 随后必须确定维护报告和评价的过程，随后必须确定维护报告和评价的过程，v 必须为每个维护要求规定一个标准化的事件序列必须为每个维护要求规定一个标准化的事件序列v 此外，还应该建立一个适用于维护活动的记录保管过此外，还应该建立一个适用于维护活动的记录保管过程，

22、并且规定复审标准程，并且规定复审标准2023-1-2630/66软件工程导论 8.3 8.3 维护任务的实施维护任务的实施v8.3.1 8.3.1 维护的组织维护的组织v8.3.2 8.3.2 维护的流程维护的流程v8.3.3 8.3.3 维护技术维护技术v8.3.4 8.3.4 维护的副作用维护的副作用2023-1-2631/66软件工程导论 8.3.1 8.3.1 维护的组织维护的组织 临时维护小组临时维护小组 长期维护小组长期维护小组v 组长、副组长、维护负责人、维护程序员组长、副组长、维护负责人、维护程序员2023-1-2632/66软件工程导论 图图8.1 8.1 维护组织成员维护组

23、织成员2023-1-2633/66软件工程导论 8.3.2 8.3.2 维护的流程维护的流程 制定维护申请报告制定维护申请报告 审查申请报告并批准审查申请报告并批准 进行维护并做详细记录进行维护并做详细记录 覆审覆审2023-1-2634/66软件工程导论 1.1.制定维护申请报告制定维护申请报告n 应该用标准化的格式表达所有软件维护要求。通常由应该用标准化的格式表达所有软件维护要求。通常由直接用户填写软件维护要求表（报告）。直接用户填写软件维护要求表（报告）。n 如果遇到了一个错误，那么必须完整描述导致出现错如果遇到了一个错误，那么必须完整描述导致出现错误的环境误的环境(包括输入数据、全部输

24、出数据以及其他有包括输入数据、全部输出数据以及其他有关信息关信息)。n 对于适应性或完善性的维护要求，应该提出一个简短对于适应性或完善性的维护要求，应该提出一个简短的需求说明书。的需求说明书。n 如前所述，由维护管理员和系统管理员评价用户提交如前所述，由维护管理员和系统管理员评价用户提交的维护要求表。的维护要求表。2023-1-2635/66软件工程导论 编写维护报告编写维护报告n“维护申请报告维护申请报告”是由用户产生的文档（即是是由用户产生的文档（即是一个外部产生的文件），它是计划维护活动的一个外部产生的文件），它是计划维护活动的基础。基础。n 针对针对“申请报告申请报告”软件组织内部还应

25、该产生出软件组织内部还应该产生出一个一个“软件修改报告软件修改报告”，它给出下述信息：，它给出下述信息：u(1)(1)所需工作量；所需工作量；u(2)(2)维护要求的性质；维护要求的性质；u(3)(3)这项要求的优先次序；这项要求的优先次序；u(4)(4)与修改有关的事后数据。与修改有关的事后数据。2023-1-2636/66软件工程导论 软件修改报告内容：软件修改报告内容：v在拟定进一步的维护计划之前，把软件修改报在拟定进一步的维护计划之前，把软件修改报告提交给变化授权人审查批准。告提交给变化授权人审查批准。2023-1-2637/66软件工程导论 2.2.维护过程维护过程v图图8.28.2

26、描绘了由一项维护要求而引出的一串事件。描绘了由一项维护要求而引出的一串事件。2023-1-2638/66软件工程导论 2.2.维护过程维护过程 首先确定要求进行的维护的类型首先确定要求进行的维护的类型 对改错性维护，从评错误的严重性开始对改错性维护，从评错误的严重性开始 对适应性和完善性维护要求，应纳入计划对适应性和完善性维护要求，应纳入计划 实施维护实施维护“救火救火”性质的维护性质的维护2023-1-2639/66软件工程导论 图图8.2 8.2 维护阶段的事件流维护阶段的事件流2023-1-2640/66软件工程导论 3.3.保存维护记录保存维护记录v保存记录的直接目的，是为了对维护活动

27、进行保存记录的直接目的，是为了对维护活动进行评价：评价：v评价维护技术的有效性；评价维护技术的有效性；v确定一个程序的确定一个程序的“优良优良”程度；程度；v评估维护的代价与效益；评估维护的代价与效益；2023-1-2641/66软件工程导论 v 保存维护记录遇到的第一个问题就是，哪些数据是值保存维护记录遇到的第一个问题就是，哪些数据是值得记录得记录?v SwansonSwanson提出了下述内容：提出了下述内容：v（1 1）程序标识；）程序标识；v（2 2）源语句数；）源语句数；v（3 3）机器指令条数；）机器指令条数；v（4 4）使用的程序设计语言；）使用的程序设计语言；v（5 5）程序安

28、装的日期；）程序安装的日期；v（6 6）自从安装以来程序运行的次数；）自从安装以来程序运行的次数；2023-1-2642/66软件工程导论 v（7 7）自从安装以来程序失效的次数；）自从安装以来程序失效的次数；v（8 8）程序变动的层次和标识；）程序变动的层次和标识；v（9 9）因程序变动而增加的源语句数；）因程序变动而增加的源语句数；v（1010）因程序变动而删除的源语句数；）因程序变动而删除的源语句数；v（1111）每个改动耗费的人时数；）每个改动耗费的人时数；v（1212）程序改动的日期；）程序改动的日期；v（1313）软件工程师的名字；）软件工程师的名字；v（1414）维护要求表的标识

29、；）维护要求表的标识；2023-1-2643/66软件工程导论 v（1515）维护类型；）维护类型；v（1616）维护开始和完成的日期；）维护开始和完成的日期；v（1717）累计用于维护的人时数；）累计用于维护的人时数；v（1818）与完成的维护相联系的纯效益。）与完成的维护相联系的纯效益。2023-1-2644/66软件工程导论 v应该为每项维护工作都收集上述数据。应该为每项维护工作都收集上述数据。v可以利用这些数据构成一个维护数据库的基础可以利用这些数据构成一个维护数据库的基础，并且像下面介绍的那样对它们进行评价。，并且像下面介绍的那样对它们进行评价。2023-1-2645/66软件工程导

30、论 4.4.评价维护活动评价维护活动v缺乏有效的数据就无法评价维护活动。如果已缺乏有效的数据就无法评价维护活动。如果已经开始保存维护记录了，则可以对维护工作做经开始保存维护记录了，则可以对维护工作做一些定量度量。一些定量度量。v至少可以从下述至少可以从下述7 7个方面度量维护工作：个方面度量维护工作：2023-1-2646/66软件工程导论 从从7 7个方面度量维护工作：个方面度量维护工作：每次程序运行平均失效的次数；每次程序运行平均失效的次数；用于每一类维护活动的总人时数；用于每一类维护活动的总人时数；平均每个程序、每种语言、每种维护类型所做平均每个程序、每种语言、每种维护类型所做的程序变动

31、数；的程序变动数；维护过程中增加或删除一个源语句平均花费的维护过程中增加或删除一个源语句平均花费的人时数；人时数；维护每种语言平均花费的人时数；维护每种语言平均花费的人时数；一张维护要求表的平均周转时间；一张维护要求表的平均周转时间；不同维护类型所占的百分比。不同维护类型所占的百分比。2023-1-2647/66软件工程导论 v根据对维护工作定量度量的结果，可以做出：根据对维护工作定量度量的结果，可以做出：v关于开发技术、语言选择、维护工作量规划、资关于开发技术、语言选择、维护工作量规划、资源分配及其他许多方面的决定源分配及其他许多方面的决定v而且可以利用这样的数据去分析评价维护任务。而且可以

32、利用这样的数据去分析评价维护任务。2023-1-2648/66软件工程导论 5.5.维护的复审维护的复审v 复审要回答下列问题复审要回答下列问题 给出当情总，即设计、代码、测试的哪些方面已经完给出当情总，即设计、代码、测试的哪些方面已经完成；成；各种维护资源已经用了哪些？还有哪些未用？各种维护资源已经用了哪些？还有哪些未用？对于这个工作，主要的、次要的障碍是什么？对于这个工作，主要的、次要的障碍是什么？v 复审对维护工作能否顺利进行有重大影响复审对维护工作能否顺利进行有重大影响2023-1-2649/66软件工程导论 8.3 8.3 维护任务的实施维护任务的实施v8.3.1 8.3.1 维护的

33、组织维护的组织v8.3.2 8.3.2 维护的流程维护的流程v8.3.3 8.3.3 维护技术维护技术v8.3.4 8.3.4 维护的副作用维护的副作用2023-1-2650/66软件工程导论 8.3.3 8.3.3 维护技术维护技术v 维护相关的技术可分为两类：维护相关的技术可分为两类：面向维护的技术面向维护的技术用于在开发期，减少错误，用于在开发期，减少错误，提高可维护性；提高可维护性；维护支援技术维护支援技术用于在维护期，提高维护的效用于在维护期，提高维护的效率和质量；率和质量；2023-1-2651/66软件工程导论 8.3 8.3 维护任务的实施维护任务的实施v8.3.1 8.3.1

34、 维护的组织维护的组织v8.3.2 8.3.2 维护的流程维护的流程v8.3.3 8.3.3 维护技术维护技术v8.3.4 8.3.4 维护的副作用维护的副作用2023-1-2652/66软件工程导论 8.3.4 8.3.4 维护的副作用维护的副作用v维护具有风险性，可以引入新的错误维护具有风险性，可以引入新的错误2023-1-2653/66软件工程导论 v 因维护而引入新的错误或缺限，被称为维护因维护而引入新的错误或缺限，被称为维护的副作用，主要有：的副作用，主要有：编码副作用编码副作用 数据副作用数据副作用 文档副作用文档副作用2023-1-2654/66软件工程导论 第第8章章 维护维护

35、8.1 8.1 软件维护的内容软件维护的内容8.2 8.2 维护的特点维护的特点8.3 8.3 维护任务的实施维护任务的实施8.4 8.4 软件的可维护性软件的可维护性2023-1-2655/66软件工程导论 8.4 8.4 软件的可维护性软件的可维护性v8.4.1 8.4.1 软件可维护性的定义软件可维护性的定义v8.4.2 8.4.2 可维护性的度量可维护性的度量v8.4.3 8.4.3 提高可维护性的方法提高可维护性的方法2023-1-2656/66软件工程导论 8.4.1 8.4.1 软件可维护性的定义软件可维护性的定义p在前面的章节中曾经多次强调，提高可维护性在前面的章节中曾经多次强

36、调，提高可维护性是支配软件工程方法学所有步骤的关键目标。是支配软件工程方法学所有步骤的关键目标。p软件的可维护性，指维护人员理解、改正、改软件的可维护性，指维护人员理解、改正、改动或改进这个软件的难易程度。动或改进这个软件的难易程度。2023-1-2657/66软件工程导论 决定软件可维护性的因素决定软件可维护性的因素 可理解性可理解性 可测试性可测试性 可修改性可修改性 可靠性可靠性 可移植性可移植性 可使用性可使用性 效率效率软件可维护性可用上面七个质量特性来衡量软件可维护性可用上面七个质量特性来衡量2023-1-2658/66软件工程导论 可理解性可理解性n 软件可理解性表现为外读者理解

37、软件的结构、软件可理解性表现为外读者理解软件的结构、功能、接口和内部处理过程的难易程度。功能、接口和内部处理过程的难易程度。n 模块化（模块结构良好，高内聚，松耦合）、模块化（模块结构良好，高内聚，松耦合）、详细的设计文档、结构化设计、源程序文档化详细的设计文档、结构化设计、源程序文档化和良好的高级程序设计语言等等，都对提高软和良好的高级程序设计语言等等，都对提高软件的可理解性有重要贡献。件的可理解性有重要贡献。2023-1-2659/66软件工程导论 可测试性可测试性n 诊断和测试的容易程度取决于软件容易理解的程度。诊断和测试的容易程度取决于软件容易理解的程度。n 良好的文档对诊断和测试是至

38、关重要的，此外，软件结良好的文档对诊断和测试是至关重要的，此外，软件结构、可用的测试工具和调试工具，以及以前设计的测试构、可用的测试工具和调试工具，以及以前设计的测试过程也都是非常重要的。过程也都是非常重要的。n 维护人员应该能够得到在开发阶段用过的测试方案，以维护人员应该能够得到在开发阶段用过的测试方案，以便进行回归测试。便进行回归测试。n 在设计阶段应该尽力把软件设计成容易测试和容易诊断在设计阶段应该尽力把软件设计成容易测试和容易诊断的。对于程序模块来说，可以用程序复杂度来度量它的的。对于程序模块来说，可以用程序复杂度来度量它的可测试性。模块的环形复杂度越大，可执行的路径就越可测试性。模块

39、的环形复杂度越大，可执行的路径就越多，因此，全面测试它的难度就越高。多，因此，全面测试它的难度就越高。2023-1-2660/66软件工程导论 可修改性可修改性n 软件容易修改的程度和设计原理和启发规则直软件容易修改的程度和设计原理和启发规则直接有关。接有关。n 耦合、内聚、信息隐藏、局部化、控制域与作耦合、内聚、信息隐藏、局部化、控制域与作用域的关系等等，都影响软件的可修改性。用域的关系等等，都影响软件的可修改性。2023-1-2661/66软件工程导论 可移植性可移植性n 软件可移植性指的是，把程序从一种计算环境软件可移植性指的是，把程序从一种计算环境（硬件配置和操作系统）转移到另一种计算

40、环（硬件配置和操作系统）转移到另一种计算环境的难易程度。境的难易程度。n 把与硬件、操作系统以及其他外部设备有关的把与硬件、操作系统以及其他外部设备有关的程序代码集中放到特定的程序模块中，可以把程序代码集中放到特定的程序模块中，可以把因环境变化而必须修改的程序局限在少数程序因环境变化而必须修改的程序局限在少数程序模块中，从而降低修改的难度。模块中，从而降低修改的难度。2023-1-2662/66软件工程导论 8.4 8.4 软件的可维护性软件的可维护性v8.4.1 8.4.1 软件可维护性的定义软件可维护性的定义v8.4.2 8.4.2 可维护性的度量可维护性的度量v8.4.3 8.4.3 提

41、高可维护性的方法提高可维护性的方法2023-1-2663/66软件工程导论 8.4.2 8.4.2 可维护性的度量可维护性的度量v 做到定量度量很困难做到定量度量很困难v 度量可维护性的七个质量特性时常用的方法：度量可维护性的七个质量特性时常用的方法：质量检查表质量检查表 质量测试质量测试 质量标准质量标准2023-1-2664/66软件工程导论 8.4 8.4 软件的可维护性软件的可维护性v8.4.1 8.4.1 软件可维护性的定义软件可维护性的定义v8.4.2 8.4.2 可维护性的度量可维护性的度量v8.4.3 8.4.3 提高可维护性的方法提高可维护性的方法2023-1-2665/66软件工程导论 8.4.3 8.4.3 提高可维护性的方法提高可维护性的方法v提高可维护性，是软件工程追求的目标提高可维护性，是软件工程追求的目标v可考虑以下五方面：可考虑以下五方面：v建立明确的软件质量目标建立明确的软件质量目标v利用先进的开发技术和工具利用先进的开发技术和工具v建立明确的质量保证工作建立明确的质量保证工作v选择可维护的程序设计语言选择可维护的程序设计语言2023-1-2666/66软件工程导论 完完