《软件工程》第8章 维护-大纲
合集下载
软件工程导论PPT课件-第8章-维护
改错或修改的要求不能及时满足引起的用户不满； 维护时的改动，引入潜伏错误，导致软件质量降低； 软件工程师从事维护工作造成的开发过程混乱。 生产率的大幅下降 维护工作量：生产性劳动+非生产性劳动。
分析评价，修改设计，编写代码等
理解代码功能、解释数据结构、接口特点和性能限度等
8.3 软件维护的特性
8.3.3 软件维护的副作用
-结构化维护
结构化维护是指软件开发过程是按照软件工程方法进 行的、各开发阶段文档齐全的软件的维护过程。
-非结构化维护
非结构化维护是指在只有源程序，缺乏必要的文档说 明，难于确定数据结构、系统接口等特性的情况下，进行 的软件维高昂
明显代价：高昂的维护费用，已上升达80%左右； 无形代价：
的工作环境，或适应已变动的数据或文件； （4）为预防软件系统的失效而对软件系统实施修改。
8.2 软件维护的分类
- 改正性维护
对在测试阶段未能发现的、在软件投入使用后才逐渐暴露出来的 错误的测试、诊断、定位、纠错，以及验证、修改的回归测试过程， 称为改正性维护。
- 完善性维护
为了满足用户在使用过程中对软件提出的新的功能与性能要求， 需要对原来的软件的功能进行修改或扩充。
- 适应性维护
使软件适应外部新的软硬件环境或者数据环境发生的变化， 而进行修改软件的过程。
- 预防性维护
为了提高软件未来的可维护性、可靠性等，或为了给未来 的改进奠定更好的基础而修改软件的过程。
8.2 软件维护的分类 预防性维护 4% 适应性维护 21% 完善性维护 50%
改正性维护 25%
四类维护占总维护的比例
修改软件设计、 复查、必要的代 码修改、单元测 试和集成测试、 验收测试和复审
分析评价，修改设计，编写代码等
理解代码功能、解释数据结构、接口特点和性能限度等
8.3 软件维护的特性
8.3.3 软件维护的副作用
-结构化维护
结构化维护是指软件开发过程是按照软件工程方法进 行的、各开发阶段文档齐全的软件的维护过程。
-非结构化维护
非结构化维护是指在只有源程序，缺乏必要的文档说 明，难于确定数据结构、系统接口等特性的情况下，进行 的软件维高昂
明显代价：高昂的维护费用，已上升达80%左右； 无形代价：
的工作环境，或适应已变动的数据或文件； （4）为预防软件系统的失效而对软件系统实施修改。
8.2 软件维护的分类
- 改正性维护
对在测试阶段未能发现的、在软件投入使用后才逐渐暴露出来的 错误的测试、诊断、定位、纠错，以及验证、修改的回归测试过程， 称为改正性维护。
- 完善性维护
为了满足用户在使用过程中对软件提出的新的功能与性能要求， 需要对原来的软件的功能进行修改或扩充。
- 适应性维护
使软件适应外部新的软硬件环境或者数据环境发生的变化， 而进行修改软件的过程。
- 预防性维护
为了提高软件未来的可维护性、可靠性等，或为了给未来 的改进奠定更好的基础而修改软件的过程。
8.2 软件维护的分类 预防性维护 4% 适应性维护 21% 完善性维护 50%
改正性维护 25%
四类维护占总维护的比例
修改软件设计、 复查、必要的代 码修改、单元测 试和集成测试、 验收测试和复审
第8章 软件维护
系统年龄： – 老系统随着不断的修改，结构越来越乱； – 维护人员经常更换，程序又变得越来越难于理解 – 许多老系统在当初并未按照软件工程的要求进行 开发，因而没有文档，或文档太少。 – 在长期的维护过程中文档在许多地方与程序实现 变得不一致，在维护时就会遇到很大困难。 数据库技术的应用：使用数据库，可以简单而有效 地管理和存储用户程序中的数据，还可以减少生成 用户报表应用软件的维护工作量。
24
8.4
软件的可维护性
许多软件的维护十分困难，原因在于这些软件 的文档不全、质量差、开发过程不注意采用好 的方法，忽视程序设计风格等。 许多维护要求并不是因为程序中出错而提出的， 而是为适应环境变化或需求变化而提出的。 为了使得软件能够易于维护，必须考虑使软件 具有可维护性。 软件可维护性是指纠正软件系统出现的错误和
14
1、维护机构 除了较大的软件开发公司外， 通常在软件维护工作方面，并 不保持一个正式的组织机构。 虽然不要求建立一个正式的维 护机构，但是在开发部门确立 一个非正式的维护机构则是非 常必要的。
15
每个维护要求都通过维护管理员转交给相应的系 统管理员去评价（系统管理员是被指定去熟悉一 小部分产品程序的技术人员）。 系统管理员对维护任务做出评价之后，由变化授 权人决定应该进行的活动。 16
缺陷，以及为满足新的要求进行修改、扩充或 压缩的难易程度。
25
8.4.1 决定软件可维护性的因素
1. 可理解性 2. 可测试性 3. 可修改性 4. 可移植性 5. 可重用性
26
1. 可理解性 软件可理解性表现为外来读者理解软件的结构、 功能、接口和内部处理过程的难易程度。模块化 （模块结构良好，高内聚，松耦合）、详细的设 计文档、结构化设计、程序内部的文档和良好的 高级程序设计语言等等，都对提高软件的可理解 性有重要贡献。 2. 可测试性 诊断和测试的容易程度取决于软件容易理解的程 度。良好的文档对诊断和测试是至关重要的，此 外，软件结构、可用的测试工具和调试工具，以 及以前设计的测试过程也都是非常重要的。维护 人员应该能够得到在开发阶段用过的测试方案， 以便进行回归测试。在设计阶段应该尽力把软件 设计成容易测试和容易诊断的。 对于程序模块来说，可以用程序复杂度来度量它 的可测试性。模块的环形复杂度越大，可执行的 路径就越多，因此，全面测试它的难度就越高。
软件工程 第8章：维护
工学二部计算机教研室
（2）并行方式
关系重大的软件一般采用同时运行新系统和 旧系统，这就是并行方式。
优点： 旧系统
① 能对系统进行全面测试，减少了新系统风险； ② 给用户熟悉新系统的时间。
缺点：
新系统 双系统要投入更多的人力财力。
工学二部计算机教研室
（3）逐步方式
分期，分部分地交付使用 克服了上面两种方式的缺点，既能防止直接转换 产生的危险性，又能减少并行方式的费用 必须考虑好新旧系统的配合问题和接口问题
工学二部计算机教研室在没有使用就解决一个 重要问题时的样子工学二部计算机教研室
向服务器上传文件时的样子
工学二部计算机教研室
当你发现上周五还非常好用， 到了周一却不能运行时的样子
工学二部计算机教研室
当所有人都在办公室挥汗如雨的加班 而你却能安然的回家度周末时的样子
工学二部计算机教研室
当听到老板说项目如果能如期完工 将会有一笔奖金时的样子
工学二部计算机教研室
文档 重构
代码 重构
逆向 工程
六、软件再工程过程
正向 工程 数据 重构 库存 目录 分析
恢复设计结果的过
文档 重构
程，从程序代码中
抽取数据结构、体
代码 重构
逆向 工程
系结构和处理过程
的设计信息。
工学二部计算机教研室
六、软件再工程过程
正向 工程 数据 分析源代码，标注 重构 库存 目录 分析
工学二部计算机教研室
（3）可修改性
与设计时采用的原则和策略相关。（耦合、内聚、
控制域和作用域、局部化程度）
（4）可移植性
（5）可重用性 决定软件可维护性的最终因素是软件设计阶段所采用
（2）并行方式
关系重大的软件一般采用同时运行新系统和 旧系统，这就是并行方式。
优点： 旧系统
① 能对系统进行全面测试，减少了新系统风险； ② 给用户熟悉新系统的时间。
缺点：
新系统 双系统要投入更多的人力财力。
工学二部计算机教研室
（3）逐步方式
分期，分部分地交付使用 克服了上面两种方式的缺点，既能防止直接转换 产生的危险性，又能减少并行方式的费用 必须考虑好新旧系统的配合问题和接口问题
工学二部计算机教研室在没有使用就解决一个 重要问题时的样子工学二部计算机教研室
向服务器上传文件时的样子
工学二部计算机教研室
当你发现上周五还非常好用， 到了周一却不能运行时的样子
工学二部计算机教研室
当所有人都在办公室挥汗如雨的加班 而你却能安然的回家度周末时的样子
工学二部计算机教研室
当听到老板说项目如果能如期完工 将会有一笔奖金时的样子
工学二部计算机教研室
文档 重构
代码 重构
逆向 工程
六、软件再工程过程
正向 工程 数据 重构 库存 目录 分析
恢复设计结果的过
文档 重构
程，从程序代码中
抽取数据结构、体
代码 重构
逆向 工程
系结构和处理过程
的设计信息。
工学二部计算机教研室
六、软件再工程过程
正向 工程 数据 分析源代码，标注 重构 库存 目录 分析
工学二部计算机教研室
（3）可修改性
与设计时采用的原则和策略相关。（耦合、内聚、
控制域和作用域、局部化程度）
（4）可移植性
（5）可重用性 决定软件可维护性的最终因素是软件设计阶段所采用
软件工程第八章软件维护
维护申请
维护决策机构
维护管理员
系统管理员
配置管理员
维护人员
每个维护申请通过维护管理员转告给系统管理员，系
统管理员一般都是对程序(某一部分)特别熟悉的技术人
员，他们对维护申请及可能引起的软件修改进行评估，
并向修改控制决策机构(一个或一组管理者)报告，由它
最后确定是否采取行动。
30
维护团队组织
31
维护报告MRF
18
软件维护的代价高昂
有形代价逐年上升： ➢1970年软件维护费用占总费用的35%——40%； ➢1980年软件维护费用占总费用的40%——60%； ➢1990年软件维护费用占总费用的70%——80%。
19
软件维护的代价高昂
• 维护费用只不过是软件维护最明显的代价，其他 一些还不明显的代价将来可能更为人们关注。其 他无形的代价还有：
• 在拟定进一步维护计划前，把软件修改报告提 交控制决策机构审查批准。
34
软件修改报告(SCR)
软件名称 源程序名称 相关文档列表
维护描述： 日期
备份程序名称
修改内容
修改原因
特别说明
增加代码行数 注释修改 修改开始日期
删除代码行数
修改代码行数
相关文档修改 修改完成日期
维护人
35
维护请求
其他
类型
改正性
7
适应性维护
• 在使用过程中，
– 外部环境（新的硬、软件配置） – 数据环境（数据库、数据格式、数据输入/
输出方式、数据存储介质）
可能发生变化。 • 为使软件适应这种变化，而去修改软件
的过程就叫做适应性维护。
8
完善性维护
• 在软件的使用过程中，用户往往会对软 件提出新的功能与性能要求。
维护决策机构
维护管理员
系统管理员
配置管理员
维护人员
每个维护申请通过维护管理员转告给系统管理员，系
统管理员一般都是对程序(某一部分)特别熟悉的技术人
员，他们对维护申请及可能引起的软件修改进行评估，
并向修改控制决策机构(一个或一组管理者)报告，由它
最后确定是否采取行动。
30
维护团队组织
31
维护报告MRF
18
软件维护的代价高昂
有形代价逐年上升： ➢1970年软件维护费用占总费用的35%——40%； ➢1980年软件维护费用占总费用的40%——60%； ➢1990年软件维护费用占总费用的70%——80%。
19
软件维护的代价高昂
• 维护费用只不过是软件维护最明显的代价，其他 一些还不明显的代价将来可能更为人们关注。其 他无形的代价还有：
• 在拟定进一步维护计划前，把软件修改报告提 交控制决策机构审查批准。
34
软件修改报告(SCR)
软件名称 源程序名称 相关文档列表
维护描述： 日期
备份程序名称
修改内容
修改原因
特别说明
增加代码行数 注释修改 修改开始日期
删除代码行数
修改代码行数
相关文档修改 修改完成日期
维护人
35
维护请求
其他
类型
改正性
7
适应性维护
• 在使用过程中，
– 外部环境（新的硬、软件配置） – 数据环境（数据库、数据格式、数据输入/
输出方式、数据存储介质）
可能发生变化。 • 为使软件适应这种变化，而去修改软件
的过程就叫做适应性维护。
8
完善性维护
• 在软件的使用过程中，用户往往会对软 件提出新的功能与性能要求。
西安工业大学《软件工程》第八章 维护
计算机科学与工程学院 软件工程(Software Engineer) 软件工程(Software Engineer)
3可维护性复审 可维护性是所有软件都应该具备的基 本特点,必须在开发阶段保证软件具有在 前面曾提到的那些可维护因素.在软件工 程过程的每一个阶段都应该考虑并努力提 高软件的可维护性,在每个阶段结束前的 技术审查和管理复审中,应该着重对可维 护性进行复审.
8.
计算机科学与工程学院
软件工程(Software Engineer) 软件工程(Software Engineer)
�
计算机科学与工程学院 软件工程(Software Engineer) 软件工程(So护的概念
软件维护可以分为以下四类: (1) 完善性维护:无论是应用软件还是系统软件,在使用软件 的过程中用户往往都会提出增加新功能或修改已有功能的 建议,还可能提出一般性的改进意见.为了满足这类要求, 需要进行完善性维护. (2) 适应性维护 适应性维护,也就是为了和变化了的环境适当地配合而进行 的修改软件的话动,是既必要又经常的维护活动. (3) 纠错性维护 因为软件测试不可能暴露出一个大型软件系统中所有潜藏的 错误,所以在任何大型程序的使用期间,用户必然会发现 程序错误,并且把他们遇到的问题报告给维护人员. (4) 预防性维护 当为了改进未来的可维护性或可靠性,或为了给未来的改进 奠定更好的基础而修改软件时,出现了通常称为预防性维 护的维护活动. 软件工程(Software Engineer) 软件工程(Software Engineer) 计算机科学与工程学院
计算机科学与工程学院
软件工程(Software Engineer) 软件工程(Software Engineer)
8.5软件维护的副作用
3可维护性复审 可维护性是所有软件都应该具备的基 本特点,必须在开发阶段保证软件具有在 前面曾提到的那些可维护因素.在软件工 程过程的每一个阶段都应该考虑并努力提 高软件的可维护性,在每个阶段结束前的 技术审查和管理复审中,应该着重对可维 护性进行复审.
8.
计算机科学与工程学院
软件工程(Software Engineer) 软件工程(Software Engineer)
�
计算机科学与工程学院 软件工程(Software Engineer) 软件工程(So护的概念
软件维护可以分为以下四类: (1) 完善性维护:无论是应用软件还是系统软件,在使用软件 的过程中用户往往都会提出增加新功能或修改已有功能的 建议,还可能提出一般性的改进意见.为了满足这类要求, 需要进行完善性维护. (2) 适应性维护 适应性维护,也就是为了和变化了的环境适当地配合而进行 的修改软件的话动,是既必要又经常的维护活动. (3) 纠错性维护 因为软件测试不可能暴露出一个大型软件系统中所有潜藏的 错误,所以在任何大型程序的使用期间,用户必然会发现 程序错误,并且把他们遇到的问题报告给维护人员. (4) 预防性维护 当为了改进未来的可维护性或可靠性,或为了给未来的改进 奠定更好的基础而修改软件时,出现了通常称为预防性维 护的维护活动. 软件工程(Software Engineer) 软件工程(Software Engineer) 计算机科学与工程学院
计算机科学与工程学院
软件工程(Software Engineer) 软件工程(Software Engineer)
8.5软件维护的副作用
《软件工程》第八章 软件维护与再工程
软件可维护性－主要影响因素
可移植性：指程序转移到一个新的计算环境的难易 程度。
影响软件可移植性的因素有：信息隐蔽原则；模块 独立；模块化；高内聚低耦合；良好的程序结构； 不用标准文本以外的语句等
一个可移植的程序应具有结构良好、灵活、不依赖 于某பைடு நூலகம்具体计算机或操作系统的性能
软件可维护性－主要影响因素
软件维护的概念－维护成本
其它一些因素：如应用的类型、数学模型、 任务的难度、IF嵌套深度、索引或下标数等， 对维护工作量也有影响
软件维护的过程－维护组织
维护组织结构图
软件维护的过程－维护组织
系统监督员一般都是对程序(某一部分)特别熟 悉的技术人员。 在维护人员对程序进行修改的过程中，由配 置管理员严格把关，控制修改的范围，对软 件配置进行审计 。 维护管理员、系统监督员、修改控制决策机 构等，均代表维护工作的某个职责范围 。
如果已经开始保存维护记录，可以对维护工作做 一些定量度量，至少可以从如下7方面进行评价：
每次程序运行平均失败的次数； 用于每一类维护活动的总人时数； 平均每个程序、每种语言、每种维护类型所必需的程序 变动数； 维护过程中增加或删除源语句平均花费的人时数； 维护每种语言平均花费的人时数； 一张维护请求表的平均周转时间； 不同维护类型所占的比例；
软件维护的过程－维护记录
软件修改报告指明：为满足维护申请报告提 出的需求所需的工作量、本次维护活动的类 别、本次维护请求的优先级、本次修改的背 景数据。在拟定进一步维护计划前，软件修 改报告要提交给修改决策机构，供进一步规 划维护活动使用 保存维护记录的第一个问题就是哪些数据值 得保存？
软件维护的过程－维护评价
软件维护的概念－维护问题
软件工程导论(第8章)
2. 文档重构；
（1）如果一个程序走向生命终点，不再经历变化，则保 持现状；（2）重构只针对当前正在修改的软件部分。
3. 逆向工程；
逆向工程是一个恢复设计结果的过程，从程序代码中抽
取数据结构、体系结构和处理过程的设计信息。
4. 代码重构；
分析源代码，标注出与结构化程序设计概念不符的 部分，重构它的代码，测试重构代码并更新代码。
2. 软件维护工作量模型
软件维护所花费的工作量，一部分用于生产
性活动，如分析、评价、修改设计、编写程序
等；另一部分用于非生产性活动，如理解代码
的含义、解释数据结构和接口特点等。
Belady和Lehman提出了一种维护工作量模型：
M=P+Ke(c-d)
其中： M：用于维护工作的总工作量； P：生产性工作量；
5. 数据重构；
当数据结构较差时，进行再工程。如以文件方式保存
数据变为以数据库方式存储。
活动以线性顺 序发生，但并非 总是这样。 对于任意一个 特定循环，可在 完成任意一个活 动后终止。
代码 重构
逆向 工程
该模型定义的6类活动： 1. 库存目录分析；
包含每个应用系统的信息，如：名称、构建日期、修改 次数、过去18个月报告的错误、用户数量、文档质量、预期 寿命，等。从中选出再工程的候选者。
13）软件工程师的名字； 15）维护类型； 14）维护要求表的标识； 16）维护开始和完成的日期；
17）累计用于维. 评价维护活动
可以从以下方面度量维护工作：
1）每次程序运行平均失效的次数；
2）用于每一类维护活动的总人时数； 3）平均每个程序、每种维护类型所做的程序变动数； 4）维护过程中增加或删除一个源语句平均花费的人时数； 5）维护每种语言平均花费的人时数；
软件工程第8章软件维护
8.1 软件维护的种类
1. 校正性维护(Corrective maintenance) 为了识别和纠正软件错误、改正软件性能上的缺陷、排
除实施中的误使用，应当进行的诊断和改正错误的过 程，就叫做校正性维护。
8.1 软件维护的种类
2. 适应性维护(Adaptive maintenance)
随着计算机的飞速发展，外部环境(新的硬、软件配置)或数据环 境(数据库、数据格式、数据输入／输出方式、数据存储介质)可 能发生变化，为了使软件适应这种变化，而去修改软件的过程就 叫做适应性维护。
8.4.1 影响可维护性的因素
除了与开发方法有关的因素之外，以下因素会对可维 护性有重要影响：
（1）软件设计人员是否受到严格的规范化工作培训； （2）是否采用主流的编程语言； （3）是否采用主流的操作系统； （4）是否采用标准化的文档资料结构和文档形成机制； （5）是否保存规范化的测试资料。
8.4.2 软件可维护性的度量
8.3 软件维护的实施
为了有效地进行软件维护，应事先就开始做组织工作。 首先需要建立维护的机构，申明提出维护申请报告的 过程及评价的过程；为每一个维护申请规定标准的处 理步骤；还必须建立维护活动的登记制度以及规定评 价和评审的标准。
8.3.2 软件维护申请报告
软件维护申请应按规定的方式提出。软件维护组织通 常提供维护申请报告(MRR， Maintenance Request Report)，或称软件问题报告，由申请维护的用户填写。
8.1 软件维护的种类
完善性维护 50％
预防性维护5％
改正性维护 20％
适应性维护 25％
图11.1 各类维护的比重
8.2 软件维护的特点
8.2.1 软件维护面临的困难 统计资料表明，有代表性的软件开发组织用于校正性
软件工程课件-第八章维护ppt
例如，在软件交付用户使用之后，解决在开发时没有测 试所有可能的执行通路而带来的问题；
2. 适应性维护
计算机科学技术领域的各个方面都在迅速进步，大约每 过38个月就有新一代的硬件宣告出现；另一方面，应用软 件的使用寿命却很容易超过十年，远远长于最初开发这个 软件时的运行环境的寿命。因此，适应性维护就是为了和 变化了的环境适当地配合而进行的修改软件的活动，是既 必要又经常的维护活动。
4. 预防性维护
当为了提高未来的可维护性或可靠性，或为了给未来的 改进工作奠定更好的基础而修改软件时，就出现了第四类维 护活动，这类维护活动称为预防性维护。通常，把预防性维 护定义为：“把今天的方法学应用于昨天的系统以满足明天 的需要”。也就是说，预防性维护就是采用先进的软件工程 方法对需要维护的软件或软件中的某一部分，主动地进行重 新设计、编码和测试。
8.3.1 维护组织 虽然通常并不需要建立正式的维护组织，但是，即使对
于一个小的软件开发团体而言，非正式地委托责任也是绝 对必要的。维护机构成员一般包括：配置管理员、维护控 制员、系统管理员、一般维护工作人员。
每个维护要求都通过维护管理员转交给相应的系统管理 员去评价，见下页图示。
维护机构
维护要求 （软件问题报告）
● 当必须把软件工程师调去从事维护工作时，将在开发 过程中造成混乱。
8.1.2.3 维护的问题很多
与软件维护有关的绝大多数问题，都可归因于软件定 义和软件开发的方法有缺点。在软件生命周期的头两个时 期没有严格而又科学的管理和规划，几乎必然会导致在最 后阶段出现问题。下面列出和软件维护有关的部分问题：
8.1.2.2 维护的代价高昂 8.1.2.3 维护的问题很多
8.1.2.1 结构化维护与非结构化维护差别悬殊
2. 适应性维护
计算机科学技术领域的各个方面都在迅速进步，大约每 过38个月就有新一代的硬件宣告出现；另一方面，应用软 件的使用寿命却很容易超过十年，远远长于最初开发这个 软件时的运行环境的寿命。因此，适应性维护就是为了和 变化了的环境适当地配合而进行的修改软件的活动，是既 必要又经常的维护活动。
4. 预防性维护
当为了提高未来的可维护性或可靠性，或为了给未来的 改进工作奠定更好的基础而修改软件时，就出现了第四类维 护活动，这类维护活动称为预防性维护。通常，把预防性维 护定义为：“把今天的方法学应用于昨天的系统以满足明天 的需要”。也就是说，预防性维护就是采用先进的软件工程 方法对需要维护的软件或软件中的某一部分，主动地进行重 新设计、编码和测试。
8.3.1 维护组织 虽然通常并不需要建立正式的维护组织，但是，即使对
于一个小的软件开发团体而言，非正式地委托责任也是绝 对必要的。维护机构成员一般包括：配置管理员、维护控 制员、系统管理员、一般维护工作人员。
每个维护要求都通过维护管理员转交给相应的系统管理 员去评价，见下页图示。
维护机构
维护要求 （软件问题报告）
● 当必须把软件工程师调去从事维护工作时，将在开发 过程中造成混乱。
8.1.2.3 维护的问题很多
与软件维护有关的绝大多数问题，都可归因于软件定 义和软件开发的方法有缺点。在软件生命周期的头两个时 期没有严格而又科学的管理和规划，几乎必然会导致在最 后阶段出现问题。下面列出和软件维护有关的部分问题：
8.1.2.2 维护的代价高昂 8.1.2.3 维护的问题很多
8.1.2.1 结构化维护与非结构化维护差别悬殊
软件工程第8章软件维护
8.1 软件质量的概念
及质量度量
软件质量的概念及质量度量
• 软件质量需求是软件用户的最终需求， 软件质量需求是软件用户的最终需求，是贯穿于软件 生命周期的一个极其重要的问题。 生命周期的一个极其重要的问题。软件开发过程中所使用 的各种开发技术、评审、验证方法以及实施的管理活动最 的各种开发技术、评审、 终都体现在软件质量中。因此， 终都体现在软件质量中。因此，讨论软件质量及其度量是 非常重要的。 非常重要的。
软件质量的概念及质量度量
• 软件质量反映了以下三方面的问题。 软件质量反映了以下三方面的问题。 • 1.软件需求是度量软件质量的基础。不符合需求的软件 软件需求是度量软件质量的基础。 软件需求是度量软件质量的基础 就不具备质量。 就不具备质量。 • 2.在各种标准中定义的一些开发准则，用来指导软件开 在各种标准中定义的一些开发准则， 在各种标准中定义的一些开发准则 发人员用工程化的方法来开发软件。 发人员用工程化的方法来开发软件。如果不遵守这些开发 准则，软件质量就得不到保证。 准则，软件质量就得不到保证。 • 3.往往有一些隐含的需求没有明确地提出来。例如，软 往往有一些隐含的需求没有明确地提出来。 往往有一些隐含的需求没有明确地提出来 例如， 件应具备良好的可维护性。 件应具备良好的可维护性。如果软件只满足那些精确定义 了的需求而没有满足这些隐含的需求， 了的需求而没有满足这些隐含的需求，软件质量就不能得 到保证。 到保证。
软件质量的概念及质量度量
4.可靠性 一个程序期望以所需的精确度完成它的预期功 可靠性:一个程序期望以所需的精确度完成它的预期功 可靠性 能的程度。 能的程度。 • 5.可移植性 把程序从一个硬件或软件系统环境移植到另 可移植性:把程序从一个硬件或软件系统环境移植到另 可移植性 一个环境所需的工作量。 一个环境所需的工作量。 • 6.可使用性 一个程序方便用户使用的程度。 可使用性:一个程序方便用户使用的程度。 可使用性 一个程序方便用户使用的程度 •
第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描述了实施软件维护的工作流程。第 一步是先确认维护要求。这需要维护人员与用户 反复协商，弄清错误概况以及对业务的影响大小， 以及用户希望做什么样的修改，并把这些情况存 入故障数据库。然后由维护组织管理员确认维护 类型。
软件工程八维护
这种情况下进行的维护活动叫做完善 性维护。
3、完善性性维护
实践表明，在几种维护活动中，完善性 维护所占的比重最大。即大部分维护工 作是改变和加强软件，而不是纠错。
完善性维护不一定是救火式的紧急维修 ，而可以是有计划、有预谋的一种再开 发活动。
事实证明，来自用户要求扩充、加强软 件功能、性能的维护活动约占整个维护 工作的50％以上。
❖ 模型表明，如果软件的开发途径不好(即，没有使用 软件工程方法学)，而且原来的开发人员不能参加维 护工作，那么维护工作量和费用将指数地增加。
影响维护工作量的因素
❖在软件的维护过程中，需要花费 大量的工作量，从而直接影响了 软件维护的成本。
❖许多软件在开发时并未考虑将来 的修改，为软件的维护带来许多 问题。
❖ 应该为每项维护工作都收集下述数据：
（1）程序标识；
（2）源语句数；
（3）机器指令条数；
（4）使用的程序设计语言；
（5）程序安装的日期；
（6）自从安装以来程序运行的次数；
（7）自从安装以来程序失效的次数；（8）程序变动的层次和标识；
（9）因程序变动而增加的源语句数；（10）因程序变动而删除的源语句数；
软件维护的管理流程
维护修改建议
进行测试
分析修改建议
N
是否合理
Y
提交管理部门审查
是否同意
Y
修改
N
撤销
提交管理部门审批
N
是否批准
Y
更新主文档
更新其他文档
提交使用
修改
8.3 软件维护过程
2. 维护报告
❖ 应该用标准化的格式表达所有软件维护要求。
软件维护人员给用户提供空白的维护要求——有时 称为软件问题报告表，由要求一项维护活动的用户 填写。
3、完善性性维护
实践表明，在几种维护活动中，完善性 维护所占的比重最大。即大部分维护工 作是改变和加强软件，而不是纠错。
完善性维护不一定是救火式的紧急维修 ，而可以是有计划、有预谋的一种再开 发活动。
事实证明，来自用户要求扩充、加强软 件功能、性能的维护活动约占整个维护 工作的50％以上。
❖ 模型表明，如果软件的开发途径不好(即，没有使用 软件工程方法学)，而且原来的开发人员不能参加维 护工作，那么维护工作量和费用将指数地增加。
影响维护工作量的因素
❖在软件的维护过程中，需要花费 大量的工作量，从而直接影响了 软件维护的成本。
❖许多软件在开发时并未考虑将来 的修改，为软件的维护带来许多 问题。
❖ 应该为每项维护工作都收集下述数据：
（1）程序标识；
（2）源语句数；
（3）机器指令条数；
（4）使用的程序设计语言；
（5）程序安装的日期；
（6）自从安装以来程序运行的次数；
（7）自从安装以来程序失效的次数；（8）程序变动的层次和标识；
（9）因程序变动而增加的源语句数；（10）因程序变动而删除的源语句数；
软件维护的管理流程
维护修改建议
进行测试
分析修改建议
N
是否合理
Y
提交管理部门审查
是否同意
Y
修改
N
撤销
提交管理部门审批
N
是否批准
Y
更新主文档
更新其他文档
提交使用
修改
8.3 软件维护过程
2. 维护报告
❖ 应该用标准化的格式表达所有软件维护要求。
软件维护人员给用户提供空白的维护要求——有时 称为软件问题报告表，由要求一项维护活动的用户 填写。
《软件工程实用教程》第8_章_软件维护技术
第8 章 軟體維Βιβλιοθήκη 技術8.2 軟體維護類型8.2.1 改正性維護 1. 利用應用軟體包，可開發出比由用戶完全 自己開發的系統可靠性更高的軟體。 2. 結構化技術，用它開發的軟體易於理解和 測試。 3. 防錯性程式設計。把自檢能力引入程式， 通過非正常狀態的檢查，提供審查跟蹤。 4. 通過週期性維護審查，在形成維護問題之 前就可確定品質缺陷。可理解性
第8 章 軟體維護技術
8.2.2 完善性維護 為了滿足日益增長的新要求，需要修改或再 開發軟體，以擴充軟體功能，增強軟體性能， 改進加工效率，提高軟體的可維護性，這些 維護活動稱為完善性維護。 8.2.3 適應性維護 為了使軟體適應新的變化而去修改軟體的維 護活動稱為適應性維護。 8.2.4 預防性維護 為以後進一步使用軟體打下良好基礎的維護 活動稱為預防性維護活動。
第8 章 軟體維護技術
8.4.2 軟體維護的副作用 1．修改代碼的副作用 2．修改數據的副作用 3．修改文檔的副作用
（1）確認維護類型 （2）實施維護 （3）維護評審
第8 章 軟體維護技術
4．整理軟體維護文檔 程式名稱； 使用的程式設計語言； 根源程式語句條數，機器代碼指令條數； 程式安裝的日期； 程式安裝後的運行次數； 與程式安裝後運行次數有關的處理故障次數； 程式改變的層次，名稱和日期； 修改程式所增加的根源程式語句條數； 修改程式所減少的根源程式語句條數；
第8 章 軟體維護技術
8.3 軟體維護技術
8.3.1 軟體維護過程 1．建立維護機構
第8 章 軟體維護技術
2．編寫軟體維護申請報告 軟體變更報告包括的內容： 所需修改變動的性質； 申請修改的優先順序； 為滿足該維護申請報告，所需的工作量（人 員數，時間數）； 預計修改後的結果。 3．確定軟體維護工作流程
第8章 维 护(Maintenance)
（6） 在完成预防性维护的过程中可以建立起完整 的软件配置。
§6 软件再工程过程
典型的软件再工程过程模型如图8.3所示，该模型 定义了6类活动。在某些情况下这些活动以线性顺 序发生，但也并非总是这样，例如，为了理解某个 程序的内部工作原理，可能在文档重构开始之前必 须先进行逆向工程。
在图8.3中显示的再工程范型是一个循环模型。这 意味着作为该范型的组成部分的每个活动都可能被 重复，而且对于任意一个特定的循环来说，过程可 以在完成任意一个活动之后终止。下面简要地介绍 该模型所定义的6类活动。
修改不及时引起用户不满 ；
维护引入新错误，降低了软件质量；等等。
• 维护工作量的经验模型：
M = P + K ec-d
其中：M = 总的维护工作量;
P = 生产性工作量 (e.g. Analysis, evaluation, design,
coding, and testing); K = 经验常数 ;
图8.3 软件再工程过程模型
1. 库存目录分析
每个软件组织都应该保存其拥有的所有应用 系统的库存目录。该目录包含关于每个应用 系统的基本信息（例如，应用系统的名字， 最初构建它的日期，已做过的实质性修改次 数，过去18个月报告的错误，用户数量，安 装它的机器数量，它的复杂程度，文档质量， 整体可维护性等级，预期寿命，在未来36个 月内的预期修改次数，业务重要程度等）。
好程序的特征：模块化、结构化、代码与设计 风格一致，高级语言实现。
度量方法：90 - 10 Test ——读源程序10分钟， 能否默写出90%？
⑵可测试性(Testability) 是指论证程序正确性的容易程度。 好程序的特征：可理解、可靠、简单。 度量方法：程序复杂度（第六章中已讨论）
§6 软件再工程过程
典型的软件再工程过程模型如图8.3所示，该模型 定义了6类活动。在某些情况下这些活动以线性顺 序发生，但也并非总是这样，例如，为了理解某个 程序的内部工作原理，可能在文档重构开始之前必 须先进行逆向工程。
在图8.3中显示的再工程范型是一个循环模型。这 意味着作为该范型的组成部分的每个活动都可能被 重复，而且对于任意一个特定的循环来说，过程可 以在完成任意一个活动之后终止。下面简要地介绍 该模型所定义的6类活动。
修改不及时引起用户不满 ；
维护引入新错误，降低了软件质量；等等。
• 维护工作量的经验模型：
M = P + K ec-d
其中：M = 总的维护工作量;
P = 生产性工作量 (e.g. Analysis, evaluation, design,
coding, and testing); K = 经验常数 ;
图8.3 软件再工程过程模型
1. 库存目录分析
每个软件组织都应该保存其拥有的所有应用 系统的库存目录。该目录包含关于每个应用 系统的基本信息（例如，应用系统的名字， 最初构建它的日期，已做过的实质性修改次 数，过去18个月报告的错误，用户数量，安 装它的机器数量，它的复杂程度，文档质量， 整体可维护性等级，预期寿命，在未来36个 月内的预期修改次数，业务重要程度等）。
好程序的特征：模块化、结构化、代码与设计 风格一致，高级语言实现。
度量方法：90 - 10 Test ——读源程序10分钟， 能否默写出90%？
⑵可测试性(Testability) 是指论证程序正确性的容易程度。 好程序的特征：可理解、可靠、简单。 度量方法：程序复杂度（第六章中已讨论）
软件工程08维护共30页
个人成果，妥善保存，请勿传播
软件的可维护性
2、文档 —— 影响可维护性的决定因素， 比代码更重要。
⑴ 用户文档： ①功能描述 —— 说明系统能做什么；
②安装文档 —— 说明安装系统的方法及适应特定 的硬件配置的方法；
③使用手册 —— 说明使用方法以及错误挽救方法；
④参考手册 —— 详尽描述用户可使用的所有系统设 施以及它们的使用方法；给出错误 信息注解表；
•开发人员往往不参加维护
•大多数软件在设计时没有考虑将来的修改
软件工程的思想至少部分地解决了与维护有 关的每一个问题。
个人成果，妥善保存，请勿传播
课程内容提纲
第8章：“维护”
– 软件维护的定义 – 软件维护的特点 – 软件维护过程 – 软件的可维护行 – 预防性维护
个人成果，妥善保存，请勿传播
⑵可测试性(Testability) 是指论证程序正确性的容易程度。 好程序的特征：可理解、可靠、简单。 度量方法：程序复杂度
个人成果，妥善保存，请勿传播
软件的可维护性
⑶ 可修改性(Reparability) 是指程序容易修改的程度。
好程序的特征：可理解、简单、通用。
度量方法：
D
A C
其中：D = 修改难度； A = 要修改模块的复杂度
大型软件的维护成本高达开发成本的4倍左右 目前国外许多软件开发组织把60％以上的人力用于维
护已有的软件 而且随着软件数量增多和使用寿命延长，这个百分比
还在持续上升
个人成果，妥善保存，请勿传播
课程内容提纲
第8章：“维护”
– 软件维护的定义 – 软件维护的特点 – 软件维护过程 – 软件的可维护性 – 预防性维护
效率
软件的可维护性
2、文档 —— 影响可维护性的决定因素， 比代码更重要。
⑴ 用户文档： ①功能描述 —— 说明系统能做什么；
②安装文档 —— 说明安装系统的方法及适应特定 的硬件配置的方法；
③使用手册 —— 说明使用方法以及错误挽救方法；
④参考手册 —— 详尽描述用户可使用的所有系统设 施以及它们的使用方法；给出错误 信息注解表；
•开发人员往往不参加维护
•大多数软件在设计时没有考虑将来的修改
软件工程的思想至少部分地解决了与维护有 关的每一个问题。
个人成果，妥善保存，请勿传播
课程内容提纲
第8章：“维护”
– 软件维护的定义 – 软件维护的特点 – 软件维护过程 – 软件的可维护行 – 预防性维护
个人成果，妥善保存，请勿传播
⑵可测试性(Testability) 是指论证程序正确性的容易程度。 好程序的特征：可理解、可靠、简单。 度量方法：程序复杂度
个人成果，妥善保存，请勿传播
软件的可维护性
⑶ 可修改性(Reparability) 是指程序容易修改的程度。
好程序的特征：可理解、简单、通用。
度量方法：
D
A C
其中：D = 修改难度； A = 要修改模块的复杂度
大型软件的维护成本高达开发成本的4倍左右 目前国外许多软件开发组织把60％以上的人力用于维
护已有的软件 而且随着软件数量增多和使用寿命延长，这个百分比
还在持续上升
个人成果，妥善保存，请勿传播
课程内容提纲
第8章：“维护”
– 软件维护的定义 – 软件维护的特点 – 软件维护过程 – 软件的可维护性 – 预防性维护
效率
软件工程教案--第八章维护XX
✓ 所需修改变动的性质； 申请修改的优先级； ✓ 为满足某个维护申请报告，所需的工作量； ✓ 预计修改后的状况。 •修改报告提交修改负责人批准后才能开始进一步安排维护工作。
软件工程教案--第八章维护XX
•软件维护 工作流程
软件工程教案--第八章维护XX
•8.3 软件维护过程
•尽管维护申请类型不同，但都要进行同样的技术工作
软件工程教案--第八章维护XX
•8.3 软件维护过程
•软件维护的机构
软件工程教案--第八章维护XX
•8.3 软件维护过程 •软件维护的机构
软件工程教案--第八章维护XX
•8.3 软件维护过程
•在修改程序的过程中，由配置管理员严格把关，控制修改的范 围，对软件配置进行审计。 •在维护之前把责任明确，可以减少维护过程中的混乱 •2、软件维护申请报告（软件问题报告） •维护申请报告，由申请维护的用户填写。 •用户必须完整地说明产生错误的情况，包括输入数据、错误清 单以及其它有关材料。 •如果申请的是适应性维护或完善性维护，用户必须提出一份修 改说明书，列出所有希望的修改。 •申请报告将由维护管理员和系统监督员来研究处理。 •他们应相应地做出软件修改报告，指明：
•8.1 软件维护的定义
在软件产品被开发出来并交付用户使用之后，就进入了软 件的运行维护阶段：
这个阶段是软件生命周期的最后一个阶段，其基本任务是 保证软件在一个相当长的时期能够正常运行。
软件维护需要的工作量非常大，平均说来，大型软件的维 护成本高达开发的4倍左右。
目前国外许多软件开发组织把60%以上的人力用于维护已 有的软件，而且随着软件产品数量增多和使用寿命延长， 这个百分比还在持续上升。
✓ 修改软件需求说明 修改软件设计
软件工程教案--第八章维护XX
•软件维护 工作流程
软件工程教案--第八章维护XX
•8.3 软件维护过程
•尽管维护申请类型不同，但都要进行同样的技术工作
软件工程教案--第八章维护XX
•8.3 软件维护过程
•软件维护的机构
软件工程教案--第八章维护XX
•8.3 软件维护过程 •软件维护的机构
软件工程教案--第八章维护XX
•8.3 软件维护过程
•在修改程序的过程中，由配置管理员严格把关，控制修改的范 围，对软件配置进行审计。 •在维护之前把责任明确，可以减少维护过程中的混乱 •2、软件维护申请报告（软件问题报告） •维护申请报告，由申请维护的用户填写。 •用户必须完整地说明产生错误的情况，包括输入数据、错误清 单以及其它有关材料。 •如果申请的是适应性维护或完善性维护，用户必须提出一份修 改说明书，列出所有希望的修改。 •申请报告将由维护管理员和系统监督员来研究处理。 •他们应相应地做出软件修改报告，指明：
•8.1 软件维护的定义
在软件产品被开发出来并交付用户使用之后，就进入了软 件的运行维护阶段：
这个阶段是软件生命周期的最后一个阶段，其基本任务是 保证软件在一个相当长的时期能够正常运行。
软件维护需要的工作量非常大，平均说来，大型软件的维 护成本高达开发的4倍左右。
目前国外许多软件开发组织把60%以上的人力用于维护已 有的软件，而且随着软件产品数量增多和使用寿命延长， 这个百分比还在持续上升。
✓ 修改软件需求说明 修改软件设计
软件工程考核知识点-第8章-软件维护
软件工程考核知识点-第8章-软件维护第一篇：软件工程考核知识点-第8章-软件维护软件工程考核知识点-第8章-软件维护第8章软件维护软件投入使用后就进入软件维护阶段。
维护阶段是软件生存周期中时间最长的一个阶段，所花费的精力和费用也是最多的一个阶段。
8.1软件维护的内容软件维护内容有四种：校正性维护，适应性维护，完善性维护和预防性维护。
1.校正性维护在软件交付使用后，由于在软件开发过程中产生的错误并没有完全彻底的在测试中发现，因此必然有一部分隐含的错误被带到维护阶段来。
这些隐含的错误在某些特定的使用环境下会暴露出来。
为了识别和纠正错误，修改软件性能上的缺陷，应进行确定和修改错误的过程，这个过程就称为校正性维护。
校正性维护占整个维护工作的20%左右。
2.适应性维护随着计算机的飞速发展，计算机硬件和软件环境也在不断发生变化，数据环境也在不断发生变化。
为了使应用软件适应这种而修改软件的过程称为适应性维护。
这种维护活动占整个维护活动的25%。
3.完善性维护在软件漫长的运行时期中，用户往往会对软件提出新的功能要求与性能要求。
这是因为用户的业务会发生变化，组织机构也会发生变化。
为了适应这些变化，应用软件原来的功能和性能需要扩充和增强，为达到这个目的而进行的维护活动称为完善性维护，占整个维护活动的50%。
4.预防性维护为了提高软件的可维护性和可靠性而对软件进行的修改称为预防性维护。
这是为以后进一步的运行和维护打好基础，占整个维护工作的4%。
8.2 维护的特点8.2.1非结构化维护和结构化维护软件的开发过程对软件的维护过程有较大的影响。
若不采用软件过程的方法开发软件，则软件只有程序而无文档，维护工作非常难，这就是一种非结构化的维护。
若采用软件工程的方法开发软件，则各阶段都有相应的文档，这容易进行维护工作，这是一种结构化的维护。
1.非结构化维护因为只有源程序，而文档很少或没有文档，维护活动只能从阅读、理解、分析源程序开始。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第8章维护
8.1 软件维护的定义
——在交付使用后，为改正错误或满足新需要而修改软件的过程。
8.2 软件维护的分类
——改正性维护
——完善性维护
——适应性维护
——预防性维护
各类维护活动都必须应用于整个软件配置，包括维护文档和维护软件的可执行代码。
8.3 软件维护的特性
8.3.1 软件维护的困难
——结构化维护定义：指软件开发过程是按照软件工程方法进行的、各开发阶段
文档齐全的软件的维护过程。
修改从设计文档开始，到编
写源代码和回归测试，再次交付使用。
——非结构化维护定义：指在只有源程序，缺乏必要的文档说明，难于确定数据
结构、系统接口等特性的情况下，进行的软件维护过程。
8.3.2 维护代价高昂
8.3.3 软件维护的副作用
——修改代码的副作用
——修改数据的副作用
——修改文档的副作用
8.4 软件维护过程
——本质：修改和压缩了的软件定义和开发过程
——过程
……（1）维护组织
……（2）维护报告
……（3）维护的事件流
……（4）保存维护记录
……（5）评价维护活动
8.5 软件的可维护性
——定义：软件的可维护性是指维护人员理解、改正、改动或改进这个软件的难易程度，它是软件质量的主要特征之一。
8.6 提高可维护性的途径
1。