软件工程导论 第8章 维护
软件工程导论课件第8章
5. 数据重构 对数据体系结构差的程序很难进行适应性和 完善性维护，因此，数据体系结构比源代码对程序 的长期生存力有更大影响。 数据重构是一种全范围的再工程活动。由于 数据重构对程序体系结构及程序中的算法有很大影 响，对数据的修改必然会导致程序体系结构或代码 层的改变。
3
2.适应性维护 为适应变化了的环境界面而修改软件的活动， 称为适应性维护。包括： （1）因硬件或支撑软件改变引起的变化； （2）将软件移植到新的机种上运行； （3）因数据环境的变化而做的变更。 这类维护大约占软件维护总工作量的25％。
4
3.完善性维护 为了满足用户要求，就得对软件进行修改和 扩充，我们称这种维护为完善性维护。完善性维护 主要包括： （1）提高处理效率； （2）提高性能。 在整个维护工作中， 完善性维护大约占50％ 左右，区居第一位。
3. 逆向工程 软件的逆向工程是，分析程序以便在比源代码 更高的抽象层次上创建出程序的某种描述的过程， 也就是说，逆向工程是一个恢复设计结果的过程。 4. 代码重构 某些老程序的体系结构比较合理，但是，一些 模块的编码方式却是难于理解、测试和维护的。在 这种情况下，可以重构这些模块的代码。 通常，代码重构并不修改程序的体系结构，它 只关注个体模块的设计细节以及在模块中定义的局 部数据结构。如果重构扩展到模块边界以外并涉及 软件体系结构，则重构变成了正向工程。
13
（四）软件维护过程 维护过程的实质是对软件定义和开发过程的修 改和压缩。维护过程的主要任务是：建立维护机构， 填写维护报告和评价，为每个维护要求规定一种规 范化的处理序列，建立对维护活动的登记制度及规 定评价复审的标准。 1.维护组织 机构中有一名维护管理员总负责，每项维护要 求都通过维护管理员转交给相应的系统管理员去评 价。系统管理员对维护任务做出评价之后，由变化 授权人决定应该进行的活动，最后由系统管理员去 执行维护任务。
软件工程第八章维护
软件工程第八章维护第一点：软件维护的定义和重要性软件维护是指在软件发布后对其进行的一系列操作和活动，旨在确保软件系统的持续可用性、可靠性和性能。
软件维护是软件开发生命周期中的一个重要环节，它涉及到对软件进行修正、优化和升级。
软件维护的重要性体现在以下几个方面：1.保障软件质量：软件在实际运行过程中可能会出现各种问题，维护可以帮助及时修复这些问题，保证软件的正常运行。
2.提高用户满意度：通过维护，可以对软件进行功能优化和界面调整，使其更加符合用户的需求，提高用户的使用体验。
3.降低风险：软件维护可以帮助提前发现并解决潜在的风险，避免因软件问题导致的损失。
4.延长软件寿命：通过不断的维护和升级，可以使软件适应不断变化的环境和需求，延长其使用寿命。
5.提高开发效率：良好的维护可以避免因软件问题导致的重复开发，提高开发团队的效率。
第二点：软件维护的类型和策略软件维护可以分为以下几种类型：1.改正性维护：这种维护类型主要是针对软件中存在的问题和错误进行修复，保证软件的正常运行。
2.适应性维护：随着环境的变化和用户需求的变化，软件需要进行相应的调整和优化，以适应新的环境和工作需求。
3.完善性维护：这种维护类型主要是针对软件的功能进行增强和扩展，以满足用户的新需求。
4.预防性维护：预防性维护是为了避免软件出现潜在的问题和风险，提前对软件进行调整和优化。
在进行软件维护时，可以采取以下策略：1.计划维护：制定详细的维护计划，包括维护的时间、内容、责任人等，确保维护工作的有序进行。
2.变更管理：对于软件的修改和更新，需要进行严格的变更管理，确保每次变更都是经过审核和评估的。
3.版本控制：通过版本控制工具，对软件的不同版本进行管理，确保软件的每个版本都是可追踪和可恢复的。
4.文档管理：对软件的维护过程和结果进行详细的文档记录，方便对软件进行管理和维护。
5.持续集成：将软件的维护工作与开发工作结合起来，通过持续集成的方式，确保软件的质量和稳定性。
软件工程导论(8)软件维护
2）适应性维护策略
➢ 在配置管理时，把硬件、操作系统和其它相关 环境因素的可能变化考虑在内，可以减少某些 适应性维护的工作量。
➢ 把与硬件、操作系统，以及其它外围设备有关 的程序归到特定的程序模块中。可把因环境变 化而必须修改的程序局部于某些程序模块之中。
➢ 使用内部程序列表、外部文件，以及处理的例 行处理包，可为维护时修改程序提供方便。
.
4
8.1.1 软件维护的定义
基本概念 软件维护 程序修改 可维护性 改善措施 逆向工程 本章小结
适应性维护（adaptive maintenance）
随着计算机的飞速发展，外 部环境（新的硬件、软件配置） 或数据环境（数据库、数据格式、 数据输入／输出方式、数据存储 介质）可能发生变化，为了使软 件适应这种变化，而修改软件的 过程叫作适应性维护。
➢ 利用应用软件包，可开发出比由 用户完全自己开发的系统可靠性 更高的软件；
➢ 使用结构化技术，开发的软件易 于理解和测试；
➢ 防错性程序设计；
➢ 通过周期性维护审查，在形成维 护问题之前就可确定质量缺陷。
.
12
8.1.1 软件维护的策略
基本概念 软件维护 程序修改 可维护性 改善措施 逆向工程 本章小结
27.11.2020
在软件维护中，影响维护 工作量的程序特性有以下6种：
➢ 系统大小 ➢ 程序设计语言 ➢ 系统年龄 ➢ 数据库技术的应用 ➢ 先进的软件开发技术 ➢ 其它
.
11
8.1.1 软件维护的策略
基本概念 软件维护 程序修改 可维护性 改善措施 逆向工程 本章小结
27.11.2020
1）改正性维护策略
27.11.2020
软件工程导论_第八章
• 完善性维护 利用前两类维护中列举的方法，也可以 减少这一类维护。特别是数据库管理系 统、程序生成器、应用软件包，可减少 维护工作量。 此外，建立软件系统的原型，把它在实 际系统开发之前提供给用户。用户通过 研究原型，进一步完善他们的功能要求， 就可以减少以后完善性维护的需要。
二、在不断增加 的，1970年占35%～40%；1980年上升到40%～ 60%。1990年上升到70%～80%。 由于大量软件的维护活动要使用较多的硬件、 软件、软件工程师等资源，使开发新的软件资源 不足而受到影响。由于维护时的改动，在软件中 引入了潜在的故障，从而降低了软件的质量。
(4) 在重新确认过程中，需邀请用 户参加。 • 维护后的验收──在交付新软件之 前，维护主管部门要检验： (1) 全部文档是否完备，并已更新； (2) 所有测试用例和测试结果已经 正确记载； (3) 记录软件配置所有副本的工作 已经完成； (4) 维护工序和责任已经确定。
适应性维护活动要占整个维护活动的25%。
3、 完善性维护
在软件漫长的运行时期中，用户往往会对软件 提出新的功能要求与性能要求，这是因为用户的 业务会发生变化，组织机构也会发生变化，为了 适应这些变化，应用软件原来的功能和性能需要 扩充和增强。例：原系统内没有帮助信息，使用 不方便，现在要加帮助信息，这种维护活动称为 完善性维护， 这种维护工作活动数量较大，占整个维护活动 50%。
开发与维护人员不是一个人或一个组织，由于 维护阶段持续时间很长，正在运行维护的软件可 能是五年前，十年前开发的，当时的开发工具、 方法、技术与当年的工具、方法、技术差异很大， 这又是维护困难的另一因素。
4、 软件维护不是一项吸引人的工作。
由于维护工作的困难性，维护工作经常遭受挫 折，而且很难出成果，不像软件开发工作那样吸 引人。
软件工程导论习题及第8章讲义
别人写的程序在没有说明文档时 理解很困难，不为人喜欢； 别人写的程序在没有说明文档时，理解很困难，不为人喜欢； 说明文档 维护持续时间都很长，开发人员一般不在现场， 维护持续时间都很长，开发人员一般不在现场，对软件没有人说 持续时间都很长 明。 绝大多数软件在设计时都没有考虑将来的修改 将来的修改。 绝大多数软件在设计时都没有考虑将来的修改。除非设计中强调 了模块的独立性，否则软件的修改既困难又易发生差错。 了模块的独立性，否则软件的修改既困难又易发生差错。
8.2 维护的特点
二.与软件维护有关的问题 与软件维护有关的问题
开发方法 开发条件 (1)模块化详细设计文档有助于理解软 软件开发及维护人员的水平 人员的水平； (1)模块化详细设计文档有助于理解软 软件开发及维护人员的水平； 件的结构 界面功能和内部流程； 结构、 影响 件的结构、界面功能和内部流程； 程序设计语言； 使用标准的程序设计语言 使用标准的程序设计语言； 维护 (2)开发过程中严格而科学的管理规划 使用标准的操作系统接口 操作系统接口； (2)开发过程中严格而科学的管理规划 使用标准的操作系统接口； 因素 及清晰可靠的文档资料对发生错误后的 使用规范化的文档资料 文档资料； 使用规范化的文档资料； 理解与纠错无疑是很重要的 无疑是很重要的。 理解与纠错无疑是很重要的。 (3)模块的独立程度对软件修改的难易 (3)模块的独立程度对软件修改的难易 模块的独立程度 程度、 程度、改进和移植影响是很大的 理解 维护 时间 困难 设计 问题 测试用例的有效性。 测试用例的有效性。
15
内容
第八章小结
一.软件维护是软件生存周期的最后一个阶段，也是持续时间 软件维护是软件生存周期的最后一个阶段，也是持续时间 最长、代价最大的一个阶段。 最长、代价最大的一个阶段。 的一个阶段 二.软件维护包括四类活动：改正性维护、适应性维护、完善 软件维护包括四类活动：改正性维护、适应性维护、 性维护和预防性维护。 性维护和预防性维护。 三.软件的可理解性、可测试性和可维修性是决定软件可维护 软件的可理解性、可测试性和可维修性是决定软件可维护 可理解性 性的基本因素。 性的基本因素。 四.软件生存周期的每个阶段和软件可维护性密切相关。 软件生存周期的每个阶段和软件可维护性密切相关。 五.文档是影响软件可维护性的决定因素。 文档是影响软件可维护性的决定因素。 是影响软件可维护性的决定因素 用户文档和系统文档， 六.文档分为用户文档和系统文档，它们都必须和程序代码同 文档分为用户文档和系统文档 时维护才有真正的价值。 时维护才有真正的价值。
软件工程导论第8章
4. 代码重构；
分析源代码，标注出与结构化程序设计概念不符的 部分，重构它的代码，测试重构代码并更新代码。
5. 数据重构；
当数据结构较差时，进行再工程。如以文件方式保存
数据变为以数据库方式存储。
6. 正向工程。
也称革新或改造，即应用软件工程的原理、概念、技 术和方法来重新开发现有系统。
求而进行的维护称为完善性维护。
4）预防性维护
为了改进软件未来的可维护性或可靠性，或
者为了给未来的改进奠定更好的基础而进行的
修改，称为预防性维护。
这种维护活动在实践中比较少见。
在各类维护中，完善性维护占软件维护工作的
大部分。
根据国外的数据统计表明，完善性维护占全部
维护活动的50%～66%，改正性维护占17%～
3）软件没有足够的文档资料，或者程序修改后 与文档资料不一致； 4）绝大多数软件在设计时没有考虑将来的修改
，所以建议采用功能独立的模块化设计原
则，增加软件的可维护性；
5）软件维护被许多人视为一种毫无吸引力的工
作，因为维护工作常常受到挫折。
要缓解以上典型问题，建议采用软件工程的方法来开发程序。
8.3 软件维护过程 1. 维护组织
4）参考手册； 5）操作员指南； 2. 系统文档
8.4.3 可维护性复审
测试结束时进行正式的可维护性复审，称为
ቤተ መጻሕፍቲ ባይዱ
配置复审，目的是：保证软件配置的所有成分
是完整的、一致的和可理解的。
8.5 预防性维护
对旧程序维护的做法：
1）反复多次做修改程序的尝试； 2）先通过仔细分析程序，尽可能多地掌握程序内部工 作细节，再有效地修改；
软件工程导论8
可修改性
耦合、内聚、信息隐藏、局部化、控制域与作用域的关系
8.4.1 决定软件可维护性的因素
可移植性
把程序从一种计算环境（硬件配置和操作系统）转移到 另一种计算环境的难易程度。 将于环境相关的额代码集中到特定模块，那么必须修改 的程序局限在少量模块，降低修改的难度 同一事物不做修改或稍加改动就在不同环境中多次重复 使用 可重用的软件构件在开发时经过很严格的测试，可靠性 比较高，改善性维护就越少 很容易修改可重用的软件构件使之再次应用在新环境中， 重用构件多，适应性和完善性维护也就越容易
维护工作
①
复审
①
8.3 软件维护过程
维护的事件流
特殊情况“救火”：当发生恶意的软件问题时，出现所谓 的“救火”维护要求。
8.3 软件维护过程
复审回答的问题
在当前处境下设计、编码或测试的哪些方面能用不同方 法进行? 哪些维护资源是应该有而事实上却没有的? 对于这项维护工作什么是主要的(以及次要的)障碍? 要求的维护类型中有预防性维护吗? 处境复查对将来维护工作的进行有重要影响，而且所提 供的反馈信息对有效地管理软件组织十分重要
8.2 软件维护的特点
8.2.1 结构化维护与非结构化维护差别巨大 8.2.2 维护的代价高昂 8.2.3 维护的问题很多
8.2.1 结构化维护与非结构化维护差别巨大
非结构化维护
软件配置的惟一成分是程序代码 步骤
① ②
③
维护活动从评价程序代码开始 软件结构、全程数据结构、系统接口、性能和(或)设计约束等经 常会产生误解，而且对程序代码所做的改动的后果也是难于估 量的 没有测试方面的文档，不可能进行回归测试
软件工程导论 第8章 维护
意见。为了满足这类要求，需要进行完善性维护。这项维护活动通常占软件维护工作的大部分。
当为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件时，出现了第四项维护活动。这项维护活动通常称为预防性维护，目前这项维护活动相对比较少。
8．2 软件维护的特点
8．2．1 结构化维护与非结构化维护差别巨大
1.非结构化维护
如果软件配置的惟一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难，对于软件结构、全程数据结构、系统接口、性能和(或)设计约束等经常会产生误解，而且对程序代码所做的改动的后果也是难于估量的：因为没有测试方面的文档，所以不可能进行回归测试(即指为了保证所做的修改没有在以前可以正常使用的软件功能中引入错误而重复过去做过的测试)。非结构化维护需要付出很大代价(浪费精力并且遭受挫折的打击)，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。
维护要求表是一个外部产生的文件，它是计划维护活动的基础。软件组织内部应该制定出一个软件修改报告，它给出下述信息：
(1)满足维护要求表中提出的要求所需要的工作量；
(2)维护要求的性质；
(3)这项要求的优先次序；
(4)与修改有关的事后数据。
在拟定进一步的维护计划之前，把软件修改报告提交给变化授权人审查批准。
保存维护记录遇到的第一个问题就是，哪些数据是值得记录的?Swanson提出了下述内容：①程序标识；②源语句数；③机器指令条数；④使用的程序设计语言；⑤程序安装的日期；⑥自从安装以来程序运行的次数；⑦自从安装以来程序失效的次数；⑧程序变动的层次和标识；⑨因程序变动而增加的源语句数；⑩因程序变动而删除的源语句数；⑾每个改动耗费的人时数；⑿程序改动的日期；⒀软件工程师的名字；⒁维护要求表的标识；⒂维护类型；⒃维护开始和完成的日期；⒄累计用于维护的人时数；⒅与完成的维护相联系的纯效益。
软件工程第八章(维护)
8.2 维护的特点
绝大多数软件在设计时没有考虑将来的修改。除非使 用强调模块独立原理的设计方法论，否则修改软件既 困难又容易发生差错。 软件维护不是一项吸引人的工作。形成这种观念很大 程度上是因为维护工作经常遭受挫折。
8.3 软件维护过程
维护过程本质上是修改和压缩了的软件定义和开 发过程。 为了有效地进行软件维护，应事先就开始做组织 工作。 首先建立一个维护组织 确定报告及评价的过程
数据库技术的应用：使用数据库，可以 简单而有效地管理和存储用户程序中的 数据，还可以减少生成用户报表应用软 件的维护工作量。 先进的软件开发技术：在软件开发时， 若使用能使软件结构比较稳定的分析与 设计技术，及程序设计技术，如面向对 象技术、复用技术等，可减少大量的工 作量。
8.2 维护的特点
软件维护的代价是降低了生产率 ，在做老程序的维护时非常明显。 例如，开发每一行源代码耗资25 美元，维护每一行源代码需要耗资 1000美元。
8.2 维护的特点
维护工作量的一个模型： M＝ P＋ K * exp（c - d）
其中： M是维护用的总工作量， P是生产性工作量， K是经验常数， c是因缺乏好的设计和文档而导致复杂性的度量）， d是维护人员对软件的熟悉程度。
8.2 维护的特点
一．结构化维护与非结构化维护的差别巨大 1.非结构化维护 如果软件配置的唯一成分是程序代码，那 么维护活动从艰苦地评价程序代码开始，而且 常常由于程序内部文档不足而使评价更困难。 而且对程序代码所做的改动的后果是难于估量 的：因为没有测试方面的文档，所以不可能进 行回归测试。 非结构化维护付出代价高昂。
为每一个维护要求规定一个标准化的事件序列
建立一个适用于维护活动的记录保管过程，并 且规定复审标准
软件工程 第八章维护
8.1软件维护的定义 8.1软件维护的定义
所谓软件维护就是在软件已经交付使用之 后，为了改正错误或满足新的需要而修改软 件的过程。 件的过程。 维护的类型有四种： 维护的类型有四种： 改正性维护 适应性维护 完善性维护 预防性维护
改正性维护
在软件交付使用后， 在软件交付使用后，因开发时测试 不彻底、不完全， 的不彻底、不完全，必然会有部分 隐藏的错误遗留到运行阶段。 隐藏的错误遗留到运行阶段。 这些隐藏下来的错误在某些特定的 这些隐藏下来的错误在某些特定的 使用环境下就会暴露出来。 使用环境下就会暴露出来。 为了识别和纠正软件错误 识别和纠正软件错误、 为了识别和纠正软件错误、改正软 件性能上的缺陷， 件性能上的缺陷，而进行诊断和改 正错误的过程就叫做改正性维护。 正错误的过程就叫做改正性维护。
维护工作量的模型
M = p + Ke
c −d
M是维护中消耗的总工作量 p是上面描述的生产性工作量 K是一个经验常数 c是因缺乏好的设计和文档而
导致复杂性的度量 是对软件熟悉程度的度量。 d是对软件熟悉程度的度量。
模型指明， 模型指明，如果使用了不好的软件 开发方法（未按软件工程要求做）， 开发方法（未按软件工程要求做）， 原来参加开发的人员或小组不能参 加维护，则工作量（及成本） 加维护，则工作量（及成本）将按 指数级增加。 指数级增加。
结构化维护 — 指软件开发过程是按照软 件工程方法进行的， 件工程方法进行的 ， 开发各阶段的文档齐 软件的维护过程， 全 ， 软件的维护过程 ， 有一整套完整的方 技术、 审定过程及文档。 案 、 技术 、 审定过程及文档 。 因此易于维 护。
8.2.2 维护的代价高昂 维护的代价高昂 维护阶段是软件生存期中最长的一个阶 段 ，软件维护的工作量占整个软件生存期的 70％以上，而且还在逐年增加。 1970年用于 70％以上，而且还在逐年增加。 1970年用于 维护已有软件的费用只占软件总预算的35 35% 维护已有软件的费用只占软件总预算的35%～ 40% 1980年上升为 40% 60% 1990年上升 年上升为40 40% ， 1980 年上升为 40% ～ 60% ， 1990 年上升 70% 80% 为70%～80%。 因此，如 降低软 件维护的成本， 件维护的成本， 就成为提高软件维护效率和 质量的关键。 质量的关键。
软件工第八章软件维护
• 情况复审的目的在于促进未来的维护工作,同时 也为有效管理软件组织提供重要的反馈信息。
软件维护记录的保存
• 有效的保存维护记录是极端重要的。 • 保存维护记录的第一个问题就是那些数据值得保存？ – Swanson为我们指出了下述内容：程序标识、源语 句数、机器指令数、使用的程序设计语言、软件安 装的日期、自安装以来软件运行的次数、自安装以 来软件失败的次数、程序变动的层次和标识、因程 序变动而增加的源语句数、因程序变动而删除的源 语句数、每个改动消耗的人时数、程序改动的日期、 软件工程师的名称、维护要求的标识、维护类型、 维护开始和完成的时间、用于维护的累计人时数、 与完成的维护相关联的纯收益。 – 应该为每项维护工作都收集上述数据。可以利用这 些数据构成一个维护数据库。
– – – – 可用的资源被软件维护所占用。 未能及时满足用户的维护要求时引起用户不满。 维护时改动软件，引入了潜在故障，降低了软件质量。 抽调人员从事维护工作，对新的开发过程造成混乱。
– 导致生产率的大幅下降。
软件维护的代价高昂
• 用于维护工作的劳动可以划分成：
– 生产性活动（如，分析评价、修改设计、编写程序 代码等） – 非生产性活动（例如，理解程序代码功能、解释数 据结构、接口特点、性能限度等）
非结构化维护
结构化维护VS非结构化维护
维护要求
结构化维护
y
n
非结构化维护
文件有吗
苦读代码
分析设计 制定计划 修改计划 编码 n n
n
找到问题 y 编码 复审通过 y 交付使用
软件工程导论PPT课件-第8章-维护
分析评价，修改设计，编写代码等
理解代码功能、解释数据结构、接口特点和性能限度等
8.3 软件维护的特性
8.3.3 软件维护的副作用
-结构化维护
结构化维护是指软件开发过程是按照软件工程方法进 行的、各开发阶段文档齐全的软件的维护过程。
-非结构化维护
非结构化维护是指在只有源程序，缺乏必要的文档说 明，难于确定数据结构、系统接口等特性的情况下，进行 的软件维高昂
明显代价：高昂的维护费用，已上升达80%左右； 无形代价：
的工作环境，或适应已变动的数据或文件； （4）为预防软件系统的失效而对软件系统实施修改。
8.2 软件维护的分类
- 改正性维护
对在测试阶段未能发现的、在软件投入使用后才逐渐暴露出来的 错误的测试、诊断、定位、纠错，以及验证、修改的回归测试过程， 称为改正性维护。
- 完善性维护
为了满足用户在使用过程中对软件提出的新的功能与性能要求， 需要对原来的软件的功能进行修改或扩充。
- 适应性维护
使软件适应外部新的软硬件环境或者数据环境发生的变化， 而进行修改软件的过程。
- 预防性维护
为了提高软件未来的可维护性、可靠性等，或为了给未来 的改进奠定更好的基础而修改软件的过程。
8.2 软件维护的分类 预防性维护 4% 适应性维护 21% 完善性维护 50%
改正性维护 25%
四类维护占总维护的比例
修改软件设计、 复查、必要的代 码修改、单元测 试和集成测试、 验收测试和复审
软件工程08-维护[1]
![软件工程08-维护[1]](https://img.taocdn.com/s3/m/ccb08dfc51e79b896902262e.png)
⑸ 可移植性(Portability)
是指程序被移到一个新环境的容易程度。
好程序的特征：结构好，不特别依赖于某一具
PPT文档演模板
体的计算机或操作系统。
软件工程08-维护[1]
软件的可维护性
⑹ 可使用性 ⑺ 效率(Efficiency)
是指程序能执行预定功能，而又不浪费机器资源 （包括内存、外存、通道容量、执行时间等等） 的程度。
PPT文档演模板
软件工程08-维护[1]
软件的可维护性
2、文档 —— 影响可维护性的决定因素， 比代码更重要。
⑴ 用户文档：
①功能描述 —— 说明系统能做什么；
②安装文档 —— 说明安装系统的方法及适应特定 的硬件配置的方法；
③使用手册 —— 说明使用方法以及错误挽救方法；
④参考手册 —— 详尽描述用户可使用的所有系统设 施以及它们的使用方法；给出错误 信息注解表；
⑤操作员指南（如果需要有系统操作员的话）—— 说明操作员处理使用中出现的各种情况的方法。
⑵系统文档：即软件生产过程中每一步产生的文档。
PPT文档演模板
软件工程08-维护[1]
3、复审 各阶段复审重点：
软件的可维护性
分析
设计
编码
测试
可靠性 可移植性 可用性
可理解性 可修改性 可测试性
可理解性 可修改性 可移植性
n 预防性维护的认识
n 维护一行源代码的代价是开发的14-20倍 n 重新设计软件体系结构的必要性 n 现有软件可作为“原型”使用，提高开发效率 n 容易明确“变更需求和变更的范围” n 可利用逆向工程和再工程工具，使部分工作自动化 n 可以建立起完善的软件配置
PPT文档演模板
软件工程第8章维护—总结
第8章维护周四上午2#211的34节，下午在1#202的78节在软件产品被开发出来并交付用户使用之后，就进入了软件的运行维护阶段。
这个阶段是软件生命周期的最后一个阶段。
大型软件的维护成本高达开发成本的4倍左右。
8.1软件维护的定义在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。
四项活动：改正性维护，适应性维护，完善性维护（一半以上），预防性维护。
8.2软件维护的特点8.2.1结构化维护与非结构化维护差别巨大1. 非结构化维护2. 结构化维护8.2.2维护的代价高昂维护工作量的一个模型：M=P+K*exp(c-d)M是维护用的总工作量，P是生产性工作量，K是经验系数，c是复杂程度（非结构化设计和缺少文档都会增加软件的复杂程度），d是维护人员对软件的熟悉程度。
8.2.3维护的问题很多1.理解别人写的程序通常非常困难；2.没有文档或文档资料显著不足；3.不能指望开发人员详细说明软件；4.设计时未考虑将来的修改；5.维护不是一项吸引人的工作。
2软件工程8.3软件维护过程1. 维护组织未必建立正式的维护组织，但是非正式的委托责任是绝对必要的。
在维护活动开始之前就明确维护责任是十分必要的，可以大大减少维护过程中可能出现的混乱。
2. 维护报告即软件修改报告。
3. 维护的事件流4. 保存维护记录5. 评价维护活动8.4软件的可维护性定义：维护人员理解、改正、改动或改进这个软件的难易程度。
8.4.1决定软件可维护性的因素1. 可理解性定义：外来读者理解软件的结构、功能、接口和内部处理过程的难易程度。
2. 可测试性可以用程序复杂度来度量它的可测试性。
3. 可修改性耦合、内聚、信息隐藏、局部化、控制域与作用域的关系等，都影响软件的可修改性。
4. 可移植性定义：把程序从一种计算环境（硬件配置和操作系统）转移到另一种计算环境的难易程度。
5. 可重用性定义：同一事物不做修改或稍加改动就在不同环境中多次重复使用。
软件工程08维护
个人成果，妥善保存，请勿传播
软件的可维护性
⑴ 可理解性(Understandability) 是指由文档代码理解功能运行的容易程度。对 外又称 user friendliness. 好程序的特征：模块化、结构化、代码与设计 风格一致，高级语言实现。 度量方法：90 - 10 Test ——读源程序10分 钟，能否默写出90%？ ⑵可测试性(Testability) 是指论证程序正确性的容易程度。 好程序的特征：可理解、可靠、简单。 度量方法：程序复杂度
软件的可维护性
⑹ 可使用性 ⑺ 效率(Efficiency) 是指程序能执行预定功能，而又不浪费机器资源 （包括内存、外存、通道容量、执行时间等等） 的程度。
个人成果，妥善保存，请勿传播
软件的可维护性
2、文档 —— 影响可维护性的决定因素， 比代码更重要。 ⑴ 用户文档： ①功能描述 —— 说明系统能做什么；
个人成果，妥善保存，请勿传播
软件的可维护性
⑶ 可修改性(Reparability) 是指程序容易修改的程度。 好程序的特征：可理解、简单、通用。 度量方法： D A
C
其中：D = 修改难度； A = 要修改模块的复杂度 C = 所有模块的平均复杂度。 D 1表示修改很困难。 ⑷ 可靠性 ⑸ 可移植性(Portability) 是指程序被移到一个新环境的容易程度。 好程序的特征：结构好，不特别依赖于某一具 体的计算机或操作系统。 个人成果，妥善保存，请勿传播
个人成果，妥善保存，请勿传播
课程内容提纲
第8章：“维护”
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第八章维护在软件产品被开发出来并交付用户使用之后，就进入了软件的运行维护阶段。
这个阶段是软件生命周期的最后一个阶段，其基本任务是保证软件在一个相当长的时期能够正常运行。
软件维护需要的工作量很大，平均说来，大型软件的维护成本高达开发成本的4倍左右。
目前国外许多软件开发组织把60％以上的人力用于维护已有的软件，而且随着软件数量增多和使用寿命延长，这个百分比还在持续上升。
将来维护工作甚至可能会束缚住软件开发组织的手脚，使他们没有余力开发新的软件。
软件工程的主要目的就是要提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。
8．1 软件维护的定义所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。
可以通过描述软件交付使用后可能进行的4项活动，具体地定义软件维护。
因为软件测试不可能暴露出一个大型软件系统中所有潜藏的错误，所以必然会有第一项维护活动：在任何大型程序的使用期间，用户必然会发现程序错误，并且把他们遇到的问题报告给维护人员。
把诊断和改正错误的过程称为改正性维护。
计算机科学技术领域的各个方面都在迅速进步，大约每过36个月就有新一代的硬件宣告出现，经常推出新操作系统或旧系统的修改版本，时常增加或修改外部设备和其他系统部件；另一方面，应用软件的使用寿命却很容易超过10年，远远长于最初开发这个软件时的运行环境的寿命。
因此，适应性维护，也就是为了和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动。
当一个软件系统顺利地运行时，常常出现第三项维护活动：在使用软件的过程中用户往往提出增加新功能或修改已有功能的建议，还可能提出一般性的改进意见。
为了满足这类要求，需要进行完善性维护。
这项维护活动通常占软件维护工作的大部分。
当为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件时，出现了第四项维护活动。
这项维护活动通常称为预防性维护，目前这项维护活动相对比较少。
从上述关于软件维护的定义不难看出，软件维护绝不仅限于纠正使用中发现的错误，事实上在全部维护活动中一半以上是完善性维护。
国外的统计数字表明，完善性维护占全部维护活动的50％～66％，改正性维护占17％～21％，适应性维护占18％一25％，其他维护活动只占4％左右。
应该注意，上述4类维护活动都必须应用于整个软件配置，维护软件文档和维护软件的可执行代码是同样重要的。
8．2 软件维护的特点8．2．1 结构化维护与非结构化维护差别巨大1.非结构化维护如果软件配置的惟一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难，对于软件结构、全程数据结构、系统接口、性能和(或)设计约束等经常会产生误解，而且对程序代码所做的改动的后果也是难于估量的：因为没有测试方面的文档，所以不可能进行回归测试(即指为了保证所做的修改没有在以前可以正常使用的软件功能中引入错误而重复过去做过的测试)。
非结构化维护需要付出很大代价(浪费精力并且遭受挫折的打击)，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。
2．结构化维护如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特点以及接口特点；估量要求的改动将带来的影响，并且计划实施途径。
然后首先修改设计并且对所做的修改进行仔细复查。
接下来编写相应的源程序代码；使用在测试说明书中包含的信息进行回归测试；最后，把修改后的软件再次交付使用。
刚才描述的事件构成结构化维护，它是在软件开发的早期应用软件工程方法学的结果。
虽然有了软件的完整配置并不能保证维护中没有问题，但是确实能减少精力的浪费并且能提高维护的总体质量。
8.2.2 维护的代价高昂在过去的几十年中，软件维护的费用稳步上升。
1970年用于维护已有软件的费用只占软件总预算的35％～40％，1980年上升为40％～60％，1990年上升为70％～90％。
维护费用只不过是软件维护的最明显的代价，其他一些现在还不明显的代价将来可能更为人们所关注。
因为可用的资源必须供维护任务使用，以致耽误甚至丧失了开发的良机，这是软件维护的一个无形的代价。
其他无形的代价还有：·当看来合理的有关改错或修改的要求不能及时满足时将引起用户不满；·由于维护时的改动，在软件中引入了潜伏的错误，从而降低了软件的质量；·当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱。
软件维护的最后一个代价是生产率的大幅度下降，这种情况在维护旧程序时常常遇到。
例如，据Gausler在1976年的报道，美国空军的飞行控制软件每条指令的开发成本是75美元，然而维护成本大约是每条指令4 000美元，也就是说，生产率下降了50倍以上。
用于维护工作的劳动可以分成生产性活动(例如，分析评价，修改设计和编写程序代码等)和非生产性活动(例如，理解程序代码的功能，解释数据结构、接口特点和性能限度等)。
下述表达式给出维护工作量的一个模型：M＝P+K exp(c—d)其中：M是维护用的总工作量，户是生产性工作量，K是经验常数，c是复杂程度(非结构化设计和缺少文档都会增加软件的复杂程度)，d是维护人员对软件的熟悉程度。
上面的模型表明，如果软件的开发途径不好(即，没有使用软件工程方法学)，而且原来的开发人员不能参加维护工作，那么维护工作量和费用将指数地增加。
8．2．3 维护的问题很多与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺点。
在软件生命周期的头两个时期没有严格而又科学的管理和规划，几乎必然会导致在最后阶段出现问题。
下面列出和软件维护有关的部分问题：(1)理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。
如果仅有程序代码没有说明文档，则会出现严重的问题。
(2)需要维护的软件往往没有合格的文档，或者文档资料显著不足。
认识到软件必须有文档仅仅是第一步，容易理解的并且和程序代码完全一致的文档才真正有价值。
(3)当要求对软件进行维护时，不能指望由开发人员给我们仔细说明软件。
由于维护阶段持续的时间很长，因此，当需要解释软件时，往往原来写程序的人已经不在附近了。
(4)绝大多数软件在设计时没有考虑将来的修改。
除非使用强调模块独立原理的设计方法学，否则修改软件既困难又容易发生差错。
(5)软件维护不是一项吸引人的工作。
形成这种观念很大程度上是因为维护工作经常遭受挫折。
上述种种问题在现有的没采用软件工程思想开发出来的软件中，都或多或少地存在着。
不应该把一种科学的方法学看做万应灵药，但是，软件工程至少部分地解决了与维护有关的每一个问题。
8．3 软件维护过程维护过程本质上是修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。
首先必须建立一个维护组织，随后必须确定报告和评价的过程，而且必须为每个维护要求规定一个标准化的事件序列。
此外，还应该建立一个适用于维护活动的记录保管过程，并且规定复审标准。
1．维护组织虽然通常并不需要建立正式的维护组织，但是，即使对于一个小的软件开发团体而言，非正式地委托责任也是绝对必要的。
每个维护要求都通过维护管理员转交给相应的系统管理员去评价。
系统管理员是被指定去熟悉一小部分产品程序的技术人员。
系统管理员对维护任务做出评价之后，由变化授权人决定应该进行的活动。
图8．1描绘了上述组织方式。
在维护活动开始之前就明确维护责任是十分必要的，这样做可以大大减少维护过程中可能出现的混乱。
·对于这项维护工作什么是主要的(以及次要的)障碍?·要求的维护类型中有预防性维护吗?处境复查对将来维护工作的进行有重要影响，而且所提供的反馈信息对有效地管理软件组织十分重要。
4．保存维护记录对于软件生命周期的所有阶段而言，以前记录保存都是不充分的，而软件维护则根本没有记录保存下来。
由于这个原因，往往不能估价维护技术的有效性，不能确定一个产品程序的“优良”程度，而且很难确定维护的实际代价是什么。
保存维护记录遇到的第一个问题就是，哪些数据是值得记录的?Swanson提出了下述内容：①程序标识；②源语句数；③机器指令条数；④使用的程序设计语言；⑤程序安装的日期；⑥自从安装以来程序运行的次数；⑦自从安装以来程序失效的次数；⑧程序变动的层次和标识；⑨因程序变动而增加的源语句数；⑩因程序变动而删除的源语句数；⑾每个改动耗费的人时数；⑿程序改动的日期；⒀软件工程师的名字；⒁维护要求表的标识；⒂维护类型；⒃维护开始和完成的日期；⒄累计用于维护的人时数；⒅与完成的维护相联系的纯效益。
应该为每项维护工作都收集上述数据。
可以利用这些数据构成一个维护数据库的基础，并且像下面介绍的那样对它们进行评价。
5．评价维护活动缺乏有效的数据就无法评价维护活动。
如果已经开始保存维护记录了，则可以对维护工作做一些定量度量。
至少可以从下述7个方面度量维护工作：(1)每次程序运行平均失效的次数；(2)用于每一类维护活动的总人时数；(3)平均每个程序、每种语言、每种维护类型所做的程序变动数；(4)维护过程中增加或删除一个源语句平均花费的人时数；(5)维护每种语言平均花费的人时数；(6)一张维护要求表的平均周转时间；(7)不同维护类型所占的百分比。
根据对维护工作定量度量的结果，可以做出关于开发技术、语言选择、维护工作量规划、资源分配及其他许多方面的决定，而且可以利用这样的数据去分析评价维护任务。
8．4 软件的可维护性可以把软件的可维护性定性地定义为：维护人员理解、改正、改动或改进这个软件的难易程度。
在前面的章节中曾经多次强调，提高可维护性是支配软件工程方法学所有步骤的关键目标。
8．4．1 决定软件可维护性的因素维护就是在软件交付使用后进行的修改，修改之前必须理解待修改的对象，修改之后应该进行必要的测试，以保证所做的修改是正确的。
如果是改正性维护，还必须预先进行调试以确定错误的具体位置。
因此，决定软件可维护性的因素主要有下述5个：1．可理解性软件可理解性表现为外来读者理解软件的结构、功能、接口和内部处理过程的难易程度。
模块化(模块结构良好，高内聚，松耦合)、详细的设计文档、结构化设计、程序内部的文档和良好的高级程序设计语言等等，都对提高软件的可理解性有重要贡献。
2．可测试性诊断和测试的容易程度取决于软件容易理解的程度。
良好的文档对诊断和测试是至关重要的，此外，软件结构、可用的测试工具和调试工具，以及以前设计的测试过程也都是非常重要的。
维护人员应该能够得到在开发阶段用过的测试方案，以便进行回归测试。
在设计阶段应该尽力把软件设计成容易测试和容易诊断的。
对于程序模块来说，可以用程序复杂度来度量它的可测试性。