软 件 工 程(软件维护)
合集下载
软件工程 软件维护(共10张PPT)
预防性 维护4%
完善性 维护
50%
纠错性 维护 25%
适应性 维护21%
纠错性维护 适应性维护 完善性维护 预防性维护
用户
维护人员
严重
进行问
修改过
涉主及要到 用软到件测的开试软发阶的段件所的有技确阶术段。定。更
结构化维护 结构化维护
— —
指指软软件件开开改发发要过过程程求是是按按照照软软件件工工纠错性
评价错误
严重程度
或
不严重
安排改正 性维护
题分析 理解分析程序
安排计划修 改程序
维护实施 人
测试程序
适应性 完美性
或 确定数据结构、系统接口等特性。
适应性维护（Adaptive Maintenance）
员
主要用到测试阶段的技术。 涉及到软件开发的所有阶段。
低
评价优
先级
将改正错误列入计划 安
高
排
进行问
复审
软件维护的管理流程如图所示：
软件维护的管理流程
N
Y
N
Y
N Y
9.2 软件维护的特性
一、结构化维护与非结构化维护
M=P+K*EXP（C - D） M=P+K*EXP（C - D）
— 指软件开发过程是按照软件工
程方法，软件的维护过程，有一整套完整的方案、 管理部门应对提交的修改方案进行分析和审查，并对修改带来的影响作充分的估计，对于不妥的修改予以撤销。
二、软件支援技术
在软件维护阶段用于提高维护工作的效率和质 量的技术。主要用到测试阶段的技术。
（信息收集、错误原因分析、软件分析与理解、 维护方案评价、代码与文档的修改、修改后的确认。）
软件维护
维 护(Maintenance)
—— 亦称 Software Evolution
1.软件维护的概念 2.维护的特点 3.维护的过程 4.可维护性 5.软件再工程过程
2018年7月2日星期一
计算机科学与工程学院
1
6.8.软件系统维护的基本概念
1.软件维护定义：
是指在软件系统已经交付使用之后，软件使用人员为了 适应新的要求、满足新的需要或为了改正软件中存在的错误 而对软件系统进行修改的过程。
2018年7月2日星期一 计算机科学与工程学院
8
维护工作量的经验模型：
M＝P＋K×exp（c－d） 其中： M是维护用的总工作量； P是生产性工作量； K是经验常数； c是复杂程度（非结构化设计和缺少文档都会增加软件 的复杂程度）； d是维护人员对软件的熟悉程度。
上面的模型表明，如果软件的开发途径不好（即，没 有使用软件工程方法学），而且原来的开发人员不能参加 维护工作，那么维护工作量（和费用）将指数地增加。
2018年7月2日星期一 计算机科学与工程学院 17
⑴ 可理解性(Understandability) 指由文档代码理解功能运行的容易程度。对外又称 user friendliness. 好程序的特征：模块化、结构化、代码与设计风格一致， 高级语言实现。 度量方法：90 - 10 Test ——读源程序10分钟，能否默写 出90%？ ⑵可测试性(Testability) 是指论证程序正确性的容易程度。 好程序的特征：可理解、可靠、简单。 度量方法：程序复杂度（第五章中已讨论）
文档：开发文档 和测试文档
缺乏文档 不能进行回归测试
原因：没有使用良好定义的方法学开发出来。 回归测试：为了保证所做的修改没有在以前可以正常使用的软件 功能中引入错误而重复过去做过的测试。
—— 亦称 Software Evolution
1.软件维护的概念 2.维护的特点 3.维护的过程 4.可维护性 5.软件再工程过程
2018年7月2日星期一
计算机科学与工程学院
1
6.8.软件系统维护的基本概念
1.软件维护定义：
是指在软件系统已经交付使用之后，软件使用人员为了 适应新的要求、满足新的需要或为了改正软件中存在的错误 而对软件系统进行修改的过程。
2018年7月2日星期一 计算机科学与工程学院
8
维护工作量的经验模型：
M＝P＋K×exp（c－d） 其中： M是维护用的总工作量； P是生产性工作量； K是经验常数； c是复杂程度（非结构化设计和缺少文档都会增加软件 的复杂程度）； d是维护人员对软件的熟悉程度。
上面的模型表明，如果软件的开发途径不好（即，没 有使用软件工程方法学），而且原来的开发人员不能参加 维护工作，那么维护工作量（和费用）将指数地增加。
2018年7月2日星期一 计算机科学与工程学院 17
⑴ 可理解性(Understandability) 指由文档代码理解功能运行的容易程度。对外又称 user friendliness. 好程序的特征：模块化、结构化、代码与设计风格一致， 高级语言实现。 度量方法：90 - 10 Test ——读源程序10分钟，能否默写 出90%？ ⑵可测试性(Testability) 是指论证程序正确性的容易程度。 好程序的特征：可理解、可靠、简单。 度量方法：程序复杂度（第五章中已讨论）
文档：开发文档 和测试文档
缺乏文档 不能进行回归测试
原因：没有使用良好定义的方法学开发出来。 回归测试：为了保证所做的修改没有在以前可以正常使用的软件 功能中引入错误而重复过去做过的测试。
软件工程 第8章 软件维护
8.4.2 软件可维护性的度量
3. 可测试性 4. 可修改性 5. 可移植性 6. 效率 7. 可使用性 8. 间接度量可维护性的方法
8.4.2 软件可维护性的度量
8. 间接度量可维护性的方法
(1) 了解问题的时间； (2) 行政管理拖延的时间； (3) 收集维护工具的时间； (4) 分析问题的时间； (5) 改变规格说明的时间； (6) 具体的改错或修改的时间； (7) 局部测试时间； (8) 整体测试时间； (9) 维护重审时间； (10) 总体恢复时间。
8.4 软件的可维护性
8.4.1 影响可维护性的因素 软件的可维护性可以简单定义为：纠正软件系统出现 的错误和缺陷,以满足新的要求, 能够被理解、被校正、 被修改或被改善的难易程度。可维护性不但与采用的 分析设计方法和开发人员的技术熟练程度有关，更重 要的是与软件项目的管理技术关系密切。软件的可维 护性成为软件开发阶段各个时期的关键目标。
8.1 软件维护的种类
完善性维护 50％
预防性维护5％
改正性维护 20％
适应性维护 25％
图11.1 各类维护的比重
8.2 软件维护的特点
8.2.1 软件维护面临的困难 统计资料表明，有代表性的软件开发组织用于校正性 维护、适应性维护、完善性维护及预防性维护的费用 占其开发总金额的70％至80％。 很多软件机构被束缚在维护工作上，这是软件维护所 带来的无形支出。
8.2.3 非结构化维护
无说明或者文档资料太少由于没有采用定义良好的软 件项目管理过程来开发软件，软件项目管理的缺陷导 致的叫“非结构化维护”,这会使软件维护付出较高的 代价.
8.2.4 结构化维护
存在完整的软件系列文档，那么维护任务就从分析设 计文件开始，确定软件的重要结构特性、功能特性和 接口特性，确定所要求的修改或校正可能产生的影响， 并且计划采用何种维护处理方法，修改设计并进行复 审，编制出新的源程序，利用文档中的信息进行回归 测试，然后重新交付软件。这种维护过程就叫做“结 构化维护”
软件工程学维护
对已经存在的软件，重新进行开发是可行的，因为： ① 维护一行源代码的成本可能是该行代码初始开发成本的
20-40倍。 ② 使用现代设计概念重新设计软件体系结构，对未来的维护
工作将有很大的帮助。 ③ 由于软件原型已经存在，软件开发生产率将远远高于平均
水平。 ④ 由于用户已经有较丰富的软件使用经验，所以很容易确定
为了使软件和变化了的环境（如软/硬件升级、新数据库 等）适当地配合而修改软件的活动。约占全部维护活动的18 % ~25%。
§1. 软件维护的定义
③ 完善性维护(perfective maintenance) 为了增加软件新功能、改已有功能（如改造界面）、增强软
件性能、提高运行效率等，而修改软件的活动。 约占全部维护活动的50% ~66%。
④ 预防性维护(preventive maintenance)
为了改进未来的可维护性或可靠性，或为了给未来的改进奠 定更好的基础而主动修改软件的活动。与其它维护活动共占总 维护的4%左右。
注：① 一般维护的工作量占生存周期70%以上，维护成本约 为开发成本的4倍；
② 文档维护与代码维护同样重要。
§2. 软件维护的特点
1、建立维护组织(maintenance team)
在维护活动开始之前就明确维护责任是十分必要的，这样可 以大大减少维护过程中可能出现的混乱。
§3. 软件维护过程
钱太少 要
任务评价
变
不干！
求 维
客户要求
化
护
授
权
人
任务评价
维护管理员
系 统 管 理 员
2、维护报告
§3. 软件维护过程
⑴ 维护要求表(Maintenance Request Form)
20-40倍。 ② 使用现代设计概念重新设计软件体系结构，对未来的维护
工作将有很大的帮助。 ③ 由于软件原型已经存在，软件开发生产率将远远高于平均
水平。 ④ 由于用户已经有较丰富的软件使用经验，所以很容易确定
为了使软件和变化了的环境（如软/硬件升级、新数据库 等）适当地配合而修改软件的活动。约占全部维护活动的18 % ~25%。
§1. 软件维护的定义
③ 完善性维护(perfective maintenance) 为了增加软件新功能、改已有功能（如改造界面）、增强软
件性能、提高运行效率等，而修改软件的活动。 约占全部维护活动的50% ~66%。
④ 预防性维护(preventive maintenance)
为了改进未来的可维护性或可靠性，或为了给未来的改进奠 定更好的基础而主动修改软件的活动。与其它维护活动共占总 维护的4%左右。
注：① 一般维护的工作量占生存周期70%以上，维护成本约 为开发成本的4倍；
② 文档维护与代码维护同样重要。
§2. 软件维护的特点
1、建立维护组织(maintenance team)
在维护活动开始之前就明确维护责任是十分必要的，这样可 以大大减少维护过程中可能出现的混乱。
§3. 软件维护过程
钱太少 要
任务评价
变
不干！
求 维
客户要求
化
护
授
权
人
任务评价
维护管理员
系 统 管 理 员
2、维护报告
§3. 软件维护过程
⑴ 维护要求表(Maintenance Request Form)
软件工程软件维护技术概述
维护的问题
与软件维护有关的绝大多数问题，都可归结于软
维 件定义和开发的方法有缺点。下面是和软件维护有关 的部分问题：
护 * 理解别人写的程序通常比较困难，而且困难
的 程度随着 软件配置成分的减少而迅速增加。
特
如果仅有程序代码没有说明文档，则问题 会现严重。
点 * 需要维护的软件往往没有合格的文档，或
软件可维护性可以定性地定义为: 维护人员理解、改正、改动和改进这 个软件的难易程度。
20前2一1页/1/12
22
可维护性
主
▪ 决定软件可维护性的因素
要 内
▪ 文档
容
▪ 可维护性复审
20前2一1页/1/12
23
决定软件可维护性的因素
可 1. 可理解性：软件可理解性表现为外来读者理解软件 的结构、接口、功能和内部过程的难易程度。
20前2一1页/1/12
5
维护的特点
主 要 内
▪ 结构化与非结构化维护 ▪ 维护的代价
容 ▪ 维护的问题
20前2一1页/1/12
6
结构化与非结构化维护
维 如果软件配置的唯一成分是程序代码，那么维护 活动从艰苦地评价程序代码开始，而且常常由于程序
护 内部文档不足而使评价更困难。这种维护方式是没有 使用良好定义的方法论开发出来的软件的必然结果。
护 成本大约是每条指令4000美元，也就是说，生产率下 降了50倍以上。 下述表达式给出维护工作量的一个模
的 型：
特
M = P + K × exp ( c - d )
点 其中： M是维护用的总工作量 P：生产性工作量
K：是经验常数
c：是复杂程度
d：是维护人员对软件的熟悉程度
软件维护
软件维护步骤
2、设计程序的修改计划 一方面：考虑对人员和资源的安排 另一方面：需要根据修改的内容及受到修改影响的内容 设计修改方案, 包括： (1) 研究程序的各个模块、模块接口及数据库等，按全 局观点提出修改计划； (2) 依次将要修改的、以及受修改影响的模块和数据结 构分离出来； (3)详细分析将要修改的、以及受修改影响的模块和数 据结构的内部细节，标明新逻辑及要修改的现有逻辑；
软件维护步骤
3、修改代码，以适应变化。
修改时应遵循原则： ① 正确、有效、谨慎地修改程序代码，尽量保持程 序的原有风格； ② 修改过程中，要随时保存前一次调试正确的源程 序代码； ③ 保持详细的维护活动和维护结果记录，保证维护 工作的可追踪性； ④ 如果修改较大，程序原有架构不符合要求，可抛 弃原有程序重新编写。
软件维护步骤
4、修改程序的副作用
副作用是指因修改软件而造成的错误或其它不希望发生的情况。 1）编码副作用：在使用程序设计语言修改源代码时可能引起的错误， 如删除或修改一个标号、标识符、一个子程序，改变程序代码的时序关系， 改变逻辑运算符，改进程序的执行效率，改变程序占用存储的大小等，都 很容易引入错误，应特别小心。 2）数据副作用：在修改数据结构时，有可能造成软件设计和数据结构 的不一致，而导致软件错误。数据副作用是修改软件信息结构引起的，如 重新定义全局或局部常量，重新初始化控制标志或指针等，都容易产生设 计与数据不相容的错误，可通过详细设计文档对数据副作用加以控制。 3）文档副作用：对数据流、软件结构、逻辑模块等进行修改时，必须 对相关技术文档进行修改，否则会导致 文档与程序功能不匹配，使文档不 能反映软件当前的状态。
软件维护的概念
软件维护的内容很广泛，根据要求维护的原因，维护的活动可分 为4种： 1、改正性维护：在软件测试过程中，没有发现的错误，带到维护阶段， 这些隐含的错误在某些特定的环境下会暴露出来。为识别和纠正这些 错误，修改软件性能上的缺陷进行的确定和修改错误的过程称为改正 性维护。 2、适应性维护：随着计算机的发展，计算机硬件和软件环境、数据环 境都在不断地发生变化，为使软件适应这种变化而进行的软件修改过 程称为适应性维护。 3、完善性维护：在软件使用过程中，用户往往会对软件提出新的功能 要求与性能要求，为满足这些新的要求，扩充软件原有的功能、改善 性能而进行的软件维护活动称为完善性维护。 4、预防性维护：为提高软件的可维护性和可靠性，为以后进一步改进 软件奠定良好基础而对软件进行的修改称为预防性维护。
软件工程基础之 软件维护
可维护性改进
代码重构
对代码进行重新组织和优化，使其更易于阅读、理解和维护 。
文档更新
更新软件文档，以反映软件的新功能、性能优化和修复的缺 陷，方便后续维护和开发。
05
适应性维护
环境变化处理
操作系统升级
当操作系统升级时，软件也需要进行相应的调整以适应新的操作系统。这可能涉及到修改软件与操作系统的接口、更 新系统调用等。
软件版本控制
为了确保软件的版本兼容性和升级的顺利进行，需要进行软件版本的控制和管理 。这可能涉及到版本号的分配、版本升级流程的制定和实施等。
兼容性测试
在软件升级后，需要进行兼容性测试以确保新版本软件与旧版本软件的兼容性。 这可能涉及到测试用例的设计、测试环境的搭建和测试执行等。
THANKS
感谢观看
04
完善性维护
功能增强
增加新功能
根据用户需求或市场需求，对软 件进行功能扩展或升级，增加新 的特性和功能。
优化现有功能
对现有功能进行改进和调整，提 高其性能、稳定性和用户体验。
性能优化
提升运行速度
通过优化算法、减少冗余计算或使用 更高效的存储结构等方式，提高软件 的运行速度。
降低资源消耗
优化软件对内存、CPU等资源的利用 ，降低软件运行成本和维护成本。
文档化与标准化
文档是软件维护的重要依据，包 括系统架构、系统功能、接口协
议等方面的文档。
标准化则是指遵循统一的编码规 范、命名规范、接口规范等，提
高代码的可读性和可维护性。
文档化和标准化有助于提高软件 的可维护性和可扩展性，降低维
护成本。
03
改正性维护
错误识别与定位
错误报告
01
软件工程——软件维护
适应性维护是指是软件适应信息技术变化和管理需求而进行的修 改。这方面的维护工作量占整个维护工作量的18%-25%。由 于目前计算机硬件价格的不断下降，各类系统软件层出不穷，人 们常常为改善系统硬件环境和运行环境而产生系统更新换代的需 求；企业的外部市场环境和管理需求的不断变化也使得各级管理 人员不断提出新的信息需求。这些因素都将导致适应性维护工作 的产生。
将软件人员抽调到维护工作中，使得其它软件 开发过程受到干扰
2023/11/3
维护的工作可划分成：
生产性活动 如，分析评价、修改设计、编写程 序代码等
非生产性活动 如，程序代码功能理解、数据结 构解释、接口特点和性能界限分析等
2023/11/3
在软件维护中，影响维护工作量的因素主要 有以下六种：
二、软件维护分类
按照维护的起因分类四类： 纠错性维护 适应性维护 完善性维护 预防性维护
2023/11/3
1. 纠错性维护（Corrective Maintenance）
——为改正软件系统中潜藏的错误而进行的活动。
纠错性维护是指在系统开发阶段已发生而系统测试阶段尚未发 现的错误。这方面的维护工作量占整个维护工作量的17%21%。所发现的错误有的不太重要，不影响系统的正常运行 ，其维护工作可随时进行；而有的错误非常重要，甚至影响整 个系统的正常运行，其维护工作必须制定计划，进行修改，并 且要进行复查和控制。
系统的大小 系统规模越大，其功能就越复杂，软件维护的工 作量也随之增大。
程序设计语言 使用功能强大的程序设计语言可以控制程序的规 模。语言的功能越强，生成程序的模块化和结构 化程度越高，所需的指令数就越少，程序的可读 性越好。
2023/11/3
系统年龄 系统使用时间越长，所进行的修改就越多，而多 次的修改可能造成系统结构混乱。由于维护人员 经常更换，程序变得越来越难于理解，加之系统 开发时文档不齐全，或在长期的维护过程中文档 在许多地方与程序实现不一致，从而使维护变得 十分困难。
将软件人员抽调到维护工作中，使得其它软件 开发过程受到干扰
2023/11/3
维护的工作可划分成：
生产性活动 如，分析评价、修改设计、编写程 序代码等
非生产性活动 如，程序代码功能理解、数据结 构解释、接口特点和性能界限分析等
2023/11/3
在软件维护中，影响维护工作量的因素主要 有以下六种：
二、软件维护分类
按照维护的起因分类四类： 纠错性维护 适应性维护 完善性维护 预防性维护
2023/11/3
1. 纠错性维护（Corrective Maintenance）
——为改正软件系统中潜藏的错误而进行的活动。
纠错性维护是指在系统开发阶段已发生而系统测试阶段尚未发 现的错误。这方面的维护工作量占整个维护工作量的17%21%。所发现的错误有的不太重要，不影响系统的正常运行 ，其维护工作可随时进行；而有的错误非常重要，甚至影响整 个系统的正常运行，其维护工作必须制定计划，进行修改，并 且要进行复查和控制。
系统的大小 系统规模越大，其功能就越复杂，软件维护的工 作量也随之增大。
程序设计语言 使用功能强大的程序设计语言可以控制程序的规 模。语言的功能越强，生成程序的模块化和结构 化程度越高，所需的指令数就越少，程序的可读 性越好。
2023/11/3
系统年龄 系统使用时间越长，所进行的修改就越多，而多 次的修改可能造成系统结构混乱。由于维护人员 经常更换，程序变得越来越难于理解，加之系统 开发时文档不齐全，或在长期的维护过程中文档 在许多地方与程序实现不一致，从而使维护变得 十分困难。
软件工程导论第8章
取数据结构、体系结构和处理过程的设计信息。
4. 代码重构；
分析源代码，标注出与结构化程序设计概念不符的 部分，重构它的代码，测试重构代码并更新代码。
5. 数据重构；
当数据结构较差时，进行再工程。如以文件方式保存
数据变为以数据库方式存储。
6. 正向工程。
也称革新或改造，即应用软件工程的原理、概念、技 术和方法来重新开发现有系统。
求而进行的维护称为完善性维护。
4）预防性维护
为了改进软件未来的可维护性或可靠性，或
者为了给未来的改进奠定更好的基础而进行的
修改，称为预防性维护。
这种维护活动在实践中比较少见。
在各类维护中，完善性维护占软件维护工作的
大部分。
根据国外的数据统计表明，完善性维护占全部
维护活动的50%～66%，改正性维护占17%～
3）软件没有足够的文档资料，或者程序修改后 与文档资料不一致； 4）绝大多数软件在设计时没有考虑将来的修改
，所以建议采用功能独立的模块化设计原
则，增加软件的可维护性；
5）软件维护被许多人视为一种毫无吸引力的工
作，因为维护工作常常受到挫折。
要缓解以上典型问题，建议采用软件工程的方法来开发程序。
8.3 软件维护过程 1. 维护组织
4）参考手册； 5）操作员指南； 2. 系统文档
8.4.3 可维护性复审
测试结束时进行正式的可维护性复审，称为
ቤተ መጻሕፍቲ ባይዱ
配置复审，目的是：保证软件配置的所有成分
是完整的、一致的和可理解的。
8.5 预防性维护
对旧程序维护的做法：
1）反复多次做修改程序的尝试； 2）先通过仔细分析程序，尽可能多地掌握程序内部工 作细节，再有效地修改；
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.2 软件维护的特点
(3) 文档副作用：对软件的数据流、软件结构、模 块逻辑等进行修改时，必须对相关技术文档进行相应修 改。否则会导致文档与程序功能不匹配、缺省条件改变 等错误，产生文档的副作用。如果对可执行软件的修改 没有反映在文档中，会产生如下文档副作用：
8.3 软件维护过程
系统监督员
维护负责人 维护小组1
维பைடு நூலகம்管理员
维护负责人 维护小组2
维护配置员
维护负责人 维护小组n
图8- 1 软件维护的组织结构
8.3 软件维护过程
维护申请提交给一个维护管理员，他把申请交给某 个系统监督员去评价。系统监督员是一位技术人员，他 必须熟悉产品程序的某一部分。一旦做出评价，由修改 负责人确定如何进行修改。维护人员对程序进行修改的 过程中，由配置管理员严格把关，控制修改的范围，对 软件配置进行审计。
2. 软件维护副作用 维护的目的是为了延长软件的寿命并让其创造更多的价 值，经过在段时间的维护，软件中的错误减少了，功能增强 了。但是，修改软件是危险的，每修改一次，可能会产生新 的潜在错误。因此，维护的副作用是指由于修改软件而造成 新的错误或其他不希望出现的情况。一般维护产生的副作用 有如下三种。
维护管理员、系统监督员和修改负责人等，均代表 维护工作的某个职责范围。修改负责人、维护管理员可 以是指定的某个人，也可以是一个包括管理人员、高级 技术人员在内的小组。系统监督员可以有其他职责，但 应具体分管某一个软件包。
8.3 软件维护过程
8.3.2 维护工作的流程 图8-2描述了实施软件维护的工作流程。第 一步是先确认维护要求。这需要维护人员与用户 反复协商，弄清错误概况以及对业务的影响大小， 以及用户希望做什么样的修改，并把这些情况存 入故障数据库。然后由维护组织管理员确认维护 类型。
8.2 软件维护的特点
(3) 文档副作用：对软件的数据流、软件结构、模 块逻辑等进行修改时，必须对相关技术文档进行相应修 改。否则会导致文档与程序功能不匹配、缺省条件改变 等错误，产生文档的副作用。如果对可执行软件的修改 没有反映在文档中，会产生如下文档副作用：
8.3 软件维护过程
系统监督员
维护负责人 维护小组1
维பைடு நூலகம்管理员
维护负责人 维护小组2
维护配置员
维护负责人 维护小组n
图8- 1 软件维护的组织结构
8.3 软件维护过程
维护申请提交给一个维护管理员，他把申请交给某 个系统监督员去评价。系统监督员是一位技术人员，他 必须熟悉产品程序的某一部分。一旦做出评价，由修改 负责人确定如何进行修改。维护人员对程序进行修改的 过程中，由配置管理员严格把关，控制修改的范围，对 软件配置进行审计。
2. 软件维护副作用 维护的目的是为了延长软件的寿命并让其创造更多的价 值，经过在段时间的维护，软件中的错误减少了，功能增强 了。但是，修改软件是危险的，每修改一次，可能会产生新 的潜在错误。因此，维护的副作用是指由于修改软件而造成 新的错误或其他不希望出现的情况。一般维护产生的副作用 有如下三种。
维护管理员、系统监督员和修改负责人等，均代表 维护工作的某个职责范围。修改负责人、维护管理员可 以是指定的某个人，也可以是一个包括管理人员、高级 技术人员在内的小组。系统监督员可以有其他职责，但 应具体分管某一个软件包。
8.3 软件维护过程
8.3.2 维护工作的流程 图8-2描述了实施软件维护的工作流程。第 一步是先确认维护要求。这需要维护人员与用户 反复协商，弄清错误概况以及对业务的影响大小， 以及用户希望做什么样的修改，并把这些情况存 入故障数据库。然后由维护组织管理员确认维护 类型。
第八章 软件维护
9
软件维护的机构10软件维 的事件流1112
软件维护工作流程
必要的技术工作 修改软件需求说明 修改软件设计 设计评审 对源程序做必要修改 单元测试 集成测试（回归测试） 确认测试 软件配置评审等。
13
8 .4 软件的可维护性
衡量软件质量的几个主要质量特性： 可维护性 可使用性 可靠性 一、软件可维护性的定义 指纠正软件系统出现的错误和缺陷，以及为 满足新的要求进行修改、扩充或压缩的容 易程度。
22
进行明确的质量保证审查
检查点复审、验收检查、周期性地维护审查、 对软件包进行检查。
选择可维护的程序设计语言 改进程序的文档 开发软件时考虑到维护
23
相关习题 1．某些软件工程师不同意“目前国外许多 软件开发组织把60%以上的人力用于维护已 有的软件”的说法，他们争论说：“我并没 有花费我的60%的时间去改正我所开发的程 序中的错误”。 请问，你对上述争论有何看法？ 2．为什么大型软件的维护成本高达开发成 本的4倍左右？
7
8.2.3 维护的问题很多 ( 1 ）理解别人写的程序通常非常困难． ( 2 ）需要维护的软件无文档或不全． ( 3 ）软件人员流动性大． ( 4 ）设计时未考虑将来修改需要，修改困难． ( 5 ）维护工作无吸引力，缺乏成就感．
8
8. 3 软件维护过程
首先建立维护组织，确定报告和评价过程， 为每个维护要求规定一个标准化的事件序 列，并记录维护活动和规定复审标准。 一、维护组识 所有软件维护申请应按规定的方式提出 维护机构通常提供“维护申请报告”或称 “软件问题报告”由申请维护的用户填写。 维护机构内部要写“软件修改报告”
26
4．假设你的任务是对一个已有的软件做重 大修改，而且只允许你从下述文档中选取两 份：(a)程序的规格说明；(b)程序的详细设 计结果（自然语言描述加上某种设计工具表 示);（c)源程序清单（其中有适当数量的注 解)。 你将选取哪两份文档？为什么这样选取？
软件维护的机构10软件维 的事件流1112
软件维护工作流程
必要的技术工作 修改软件需求说明 修改软件设计 设计评审 对源程序做必要修改 单元测试 集成测试（回归测试） 确认测试 软件配置评审等。
13
8 .4 软件的可维护性
衡量软件质量的几个主要质量特性： 可维护性 可使用性 可靠性 一、软件可维护性的定义 指纠正软件系统出现的错误和缺陷，以及为 满足新的要求进行修改、扩充或压缩的容 易程度。
22
进行明确的质量保证审查
检查点复审、验收检查、周期性地维护审查、 对软件包进行检查。
选择可维护的程序设计语言 改进程序的文档 开发软件时考虑到维护
23
相关习题 1．某些软件工程师不同意“目前国外许多 软件开发组织把60%以上的人力用于维护已 有的软件”的说法，他们争论说：“我并没 有花费我的60%的时间去改正我所开发的程 序中的错误”。 请问，你对上述争论有何看法？ 2．为什么大型软件的维护成本高达开发成 本的4倍左右？
7
8.2.3 维护的问题很多 ( 1 ）理解别人写的程序通常非常困难． ( 2 ）需要维护的软件无文档或不全． ( 3 ）软件人员流动性大． ( 4 ）设计时未考虑将来修改需要，修改困难． ( 5 ）维护工作无吸引力，缺乏成就感．
8
8. 3 软件维护过程
首先建立维护组织，确定报告和评价过程， 为每个维护要求规定一个标准化的事件序 列，并记录维护活动和规定复审标准。 一、维护组识 所有软件维护申请应按规定的方式提出 维护机构通常提供“维护申请报告”或称 “软件问题报告”由申请维护的用户填写。 维护机构内部要写“软件修改报告”
26
4．假设你的任务是对一个已有的软件做重 大修改，而且只允许你从下述文档中选取两 份：(a)程序的规格说明；(b)程序的详细设 计结果（自然语言描述加上某种设计工具表 示);（c)源程序清单（其中有适当数量的注 解)。 你将选取哪两份文档？为什么这样选取？
软件工程课本讲解第6章软件维护
例如，开发每一行源代码耗资25美 元，维护每一行源代码需要耗资 1000美元。
维护工作量包括生产性活动（如分 析和评价、设计修改和实现）和 “轮转”活动（如力图理解代码在 做什么、试图判明数据结构、接口 特性、性能界限等）。
21
维护工作量的模型
MpKced
M是维护中消耗的总工作量 p是上面描述的生产性工作量 K是一个经验常数 c是因缺乏好的设计和文档而导致
复杂性的度量 d是对软件熟悉程度的度量。
22
模型指明，如果使用了不好的软件 开发方法（未按软件工程要求做）， 原来参加开发的人员或小组不能参 加维护，则工作量（及成本）将按 指数级增加。
23
6.2 软件维护实施活动
为了有效地进行软件维护，应事先 就开始做组织工作。 首先建立维护的机构 申明提出维护申请报告的过程及 评价的过程 为每一个维护申请规定标准的处 理步骤 建立维护活动的登记制度以及规 定评价和评审的标准。
3
一、软件维护的定义
在软件运行／维护阶段对软件产品进行的修改就是 所谓的维护。
软件维护是软件生存周期的最后一个阶段,不属于系统开发的过程。
问题
内
容
维护 满足用户对已开发产品的性能与运行环境不断提高的要求，进而
目的 达到延长软件寿命的目的。
改正性 对程序使用期间发现的程序错误进行诊断和改正的过程；
改正性 17—21% 适应性 18—25%
完善性 50—66% 预防性 4%左右
软件的易维护性是软件开发过程中每个步骤的一个关键目标。维护费用占软件总支
出的20-30%到70-80%。而无形的代价更是无法估计的。
4
改正性维护
在软件交付使用后，因开发时测试 的不彻底、不完全，必然会有部分 隐藏的错误遗留到运行阶段。
维护工作量包括生产性活动（如分 析和评价、设计修改和实现）和 “轮转”活动（如力图理解代码在 做什么、试图判明数据结构、接口 特性、性能界限等）。
21
维护工作量的模型
MpKced
M是维护中消耗的总工作量 p是上面描述的生产性工作量 K是一个经验常数 c是因缺乏好的设计和文档而导致
复杂性的度量 d是对软件熟悉程度的度量。
22
模型指明，如果使用了不好的软件 开发方法（未按软件工程要求做）， 原来参加开发的人员或小组不能参 加维护，则工作量（及成本）将按 指数级增加。
23
6.2 软件维护实施活动
为了有效地进行软件维护，应事先 就开始做组织工作。 首先建立维护的机构 申明提出维护申请报告的过程及 评价的过程 为每一个维护申请规定标准的处 理步骤 建立维护活动的登记制度以及规 定评价和评审的标准。
3
一、软件维护的定义
在软件运行／维护阶段对软件产品进行的修改就是 所谓的维护。
软件维护是软件生存周期的最后一个阶段,不属于系统开发的过程。
问题
内
容
维护 满足用户对已开发产品的性能与运行环境不断提高的要求，进而
目的 达到延长软件寿命的目的。
改正性 对程序使用期间发现的程序错误进行诊断和改正的过程；
改正性 17—21% 适应性 18—25%
完善性 50—66% 预防性 4%左右
软件的易维护性是软件开发过程中每个步骤的一个关键目标。维护费用占软件总支
出的20-30%到70-80%。而无形的代价更是无法估计的。
4
改正性维护
在软件交付使用后，因开发时测试 的不彻底、不完全，必然会有部分 隐藏的错误遗留到运行阶段。
软件工程维护
0
软件生命周期
软件生命周期每个阶段的基本任务
1. 问题 2. 可行 3. 需求 4. 总体 定义 性研究 分析 设计
1.3 软件生命周期
软件生命周期
1
软件生命周期每个阶段的基本任务
5.设详计细和6.单试编元码测
7. 综合 测试
8. 软件 维护
在实际从事软件开发工作时，软件规模、种类、开发环 境及开发时使用的技术方法等因素，都影响阶段的划分。
8.1.1.改正性维护
8.1 软件维护的定义
9
8.1.2. 适应性维护——第二项维护活环境适当地进 行的修改软件的活动。
实际寿命
旧版本
预期寿命
第8章 维护
8.1.2.适应性维护
8.1 软件维护的定义
10
8.1.3.完善性维护
当一个软件系统顺利地运行时，常常出现第三 项维护活动：在使用软件的过程中用户往往提出增 加新功能或修改已有功能的建议，还可能提出一般 性的改进意见。为了满足这类要求，需要进行完善 性维护。这项维护活动通常占软件维护工作的大部 分。
条指令的开发成本是75美元，然而维护成本大约是每条指 令4000美元，也就是说，生产率下降为约1/50。
第8章 维护
8.2.2. 维护的代价高昂
8.2 软件维护的特点
19
用于维护工作的劳动可以分：下述表达式给出维护工作量的一个
A. 生产性活动
模型：M=P+K×exp(c-d)，其中：
➢ 分析评价
M：维护用的总工作量
可以通过描述软件交付使用后可能进行 的4项活动，具体地定义软件维护。
第8章 维护
8.1 软件维护的定义
8.1 软件维护的定义
7
从上述关于软件维护的 定义不难看出，软件维 护绝不仅限于纠正使用 中发现的错误，事实上 在全部维护活动中一半 以上是完善性维护。 应该注意，上述4类维护 活动都必须应用于整个 软件配置，维护软件文 档和维护软件的可执行 代码是同样重要的。
软件生命周期
软件生命周期每个阶段的基本任务
1. 问题 2. 可行 3. 需求 4. 总体 定义 性研究 分析 设计
1.3 软件生命周期
软件生命周期
1
软件生命周期每个阶段的基本任务
5.设详计细和6.单试编元码测
7. 综合 测试
8. 软件 维护
在实际从事软件开发工作时，软件规模、种类、开发环 境及开发时使用的技术方法等因素，都影响阶段的划分。
8.1.1.改正性维护
8.1 软件维护的定义
9
8.1.2. 适应性维护——第二项维护活环境适当地进 行的修改软件的活动。
实际寿命
旧版本
预期寿命
第8章 维护
8.1.2.适应性维护
8.1 软件维护的定义
10
8.1.3.完善性维护
当一个软件系统顺利地运行时，常常出现第三 项维护活动：在使用软件的过程中用户往往提出增 加新功能或修改已有功能的建议，还可能提出一般 性的改进意见。为了满足这类要求，需要进行完善 性维护。这项维护活动通常占软件维护工作的大部 分。
条指令的开发成本是75美元，然而维护成本大约是每条指 令4000美元，也就是说，生产率下降为约1/50。
第8章 维护
8.2.2. 维护的代价高昂
8.2 软件维护的特点
19
用于维护工作的劳动可以分：下述表达式给出维护工作量的一个
A. 生产性活动
模型：M=P+K×exp(c-d)，其中：
➢ 分析评价
M：维护用的总工作量
可以通过描述软件交付使用后可能进行 的4项活动，具体地定义软件维护。
第8章 维护
8.1 软件维护的定义
8.1 软件维护的定义
7
从上述关于软件维护的 定义不难看出，软件维 护绝不仅限于纠正使用 中发现的错误，事实上 在全部维护活动中一半 以上是完善性维护。 应该注意，上述4类维护 活动都必须应用于整个 软件配置，维护软件文 档和维护软件的可执行 代码是同样重要的。
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
误 适应性维护。适应外部环境的变化 完善性维护。改进原有的软件 预防性维护。提高可维护性和可靠性
1、软件维护概述
1.3 维护的工作量分配
1、软件维护概述
1.4 软件维护中存在的主要问题
程序的源代码或算法可读性差，加大了软件维护 的难度。 文档丢失或文档不全。 软件的开发人员和软件维护人员分离，软件维护 的逆向工程花费软件维护人员的大量时间和精力。 软件本身可修改性差，无法二次开发。 开发方和出资方对软件维护的认识不足，资金追 加不够，软件维护工作无法深入。 软件维护工作繁琐，时间长，影响软件的正常使 用，容易导致用户对软件维护人员和软件系统的 不信任。
2.3 编写维护报告
申请表编号:
项目编号 改正性 维 软 件 维 护 完善性 适应性 预防性 硬 件 维 护 维修要求: 项目名称
申请日期: 别
系统设备
外围设备 申请评价结论: 远程/现场
评价负责人: 评价时间:
维修优先级
维护方式
申请人
2、软件维护过程
2.4 进行软件修改
1、软件维护概述
1.5 软件维护的内容
程序维护
文件备份及修复 查杀病毒
硬件维护
系统优化
1、软件维护概述
1.6 软件维护工作的特点
软件维护耗时费力
软件维护的代价昂贵 远程维护是现代软件维护的新途径 软件复用技术简化了软件维护
1、软件维护概述
1.7 软件的可维护性
可理解性 可靠性 可测试性 可修改性 可移植性 可使用性
2 软件维护过程
2.1 建立维护的机构 2.2 规范维护流程
2.3 编写维护报告
2.4 进行软件修改 2.5 保存维护记录 2.6 评价维护结果
2、软件维护过程
2.1 维护机构
三种常用的软件维护组织方式
(1)由系统管理员提出软件修改请求报告；
(2)由有关领导审批请求报告；
(3)手续完备后，实施软件的修改； (4)进行软件修改后的测试与试运行； (5) 作总结调整并修改文档资料； (6)交付修改的软件
(7)软件做新的备份，并同定稿的文档资料一起存档，这里的文档
主要应包括以下内容： 维护的审批人、提请人、维护人的姓名、维护时间、修改原因、 修改的内容、修改后的现状。
每类型的维护 活动的总人数
3 逆向工程
逆向工程是通过源程序，甚至是目标程序，由此导 出设计模型、分析模型的过程。 逆向工程被用到了软件维护上，通过从老化系统的 源代码中提取程序流程设计、系统结构设计，甚至 数据流图，由此而给老化系统的维护带来方便。
4 程序修改的步骤
4.1 分析和理解程序
新环境下的老问题
维护的价值
软件维护是软件的成本的重要组成部分 不堪重负的维护 维护也是商机
1、软件维护概述
1.2 软件维护的定义
定义
在软件运行／维护阶段对软件产品进行的修改
就是所谓的维护，以保障软件能够正常运行。
维护的类型
改正性维护。纠正在使用过程中暴露出来的错
4.2 修改程序
设计程序的修改计划 修改代码，以适应变化 修改程序的副作用
修改代码的副作用 在修改源代码时，都可能引入错误。
修改数据的副作用 可能造成软件设计与数据结构不匹配 文档的副作用。 软件文档不能反映软件的当前状态。
4.3 重新验证程序
确定测试
确定修改程序的正确性 确定满足维护的请求
作业
对于ATM系统，分析一下该系统主要的维 护项目有哪些？应该采用哪些维护策略？
2、软件维护过程
2.5 保存维护记录
维护请求
变动的程序和文档 维护日志
维护效果
客户确定
2、软件维护过程
2.6 评价维护结果
单位维护要求 表 周转时间
平均每个程序、每种语 言、每种维护所作的程 序变动数
不同语言花费 人时数
各种维护比例
软件维护评价
单位源语句增 减花费人时数
每次程序运行 平均失效次数
回归测试
确定未修改程序的正确性 确定未修改功能的正确性
小结
本章介绍软件维护的特点、软件维护活动的类型 和维护过程，以及提高软件可维护性的技术。 软件维护是软件生存周期的最后一个阶段，也是 持续时间最长、工作量最大的一项不可避免的过 程。软件维护的基本目标和任务是改正错误、增 加功能、提高质量、优化软件、延长软件寿命， 提高软件产品价值。 软件维护活动分为改正性维护、完善性维护、适 应性维护和预防性维护四种类型。
留下开发人员做维护 公司建立单独的维护部门进行维护
维护外包
维护的三个层次
客户自己维护 技术支持人员维护 开发人员维护
2、软件维护过程
2.2 维护管理流程
系统 用户
申请否决
申请批准
结果反馈
维护申请
申请评价
维护实施
软件测试
软件检查
交付使用
维护 人员
填写维护记录
2、软件维护过程
软 件 工 程
第21讲：软件维护
主讲人：阳王东 Email：yangwangdong@
主要内容
1、软件维护概述
2、软件维护过程 3、逆向工程 4、程序修改的步骤及修改的副作用
1、软件系统概述
1.1 背景知识
软件的生命周期
维护是延长软件生命周期的途径
千年虫问题
4.2 修改程序 4.3 重新验证程序
4、程序修改
4.1 分析和理解程序
理解程序的功能和目标； 掌握程序的结构信息，即从程序中细分出 若干结构成分。如程序系统结构、 控制结 构、数据结构和输入／输出结构等； 了解数据流信息，即涉及到的数据来源何 处，在哪里被使用； 了解控制流信息，即执行每条路径的结果； 理解程序的操作(使用)要求。