9.2 软件维护的特点
9.3 软件维护过程
9.4 软件可维护性
9.5 软件维护的副作用退出第九章 软件维护
9.1 软件维护的概念
9.1 软件维护的概念
9.1.1 软件维护的种类
9.1.2 影响维护工作量的因素退出一般来说,要求进行维护的原因大致有以下几种：
（ 1） 改正程序中的错误和缺陷 。
（ 2） 改进设计以适应新的软,硬件环境 。
（ 3） 增加新的应用范围 。
综合以上几种要求进行维护的原因,我们可以把软件维护分为以下几类：
1,改正性维护
2,适应性维护
3,完善性维护
4,预防性维护
9.1.1 软件维护的种类
9.1.2 影响维护工作量的因素
1．系统的规模
2．系统的年龄
3．系统的结构
4．程序设计语言
5．文档的质量
9,2 软件维护的特点
9.2.1 软件工程与软件维护的关系
9.2.2 维护成本退出
9.2.3 维护的成本
9.2.1 软件工程与软件维护的关系配置评价设计计划途径修改设计重新编码评价代码
？
复查重新编码复查维护要求交付使用软件 代码无形的维护成本：
（ 1） 一些看起来是合理的改错或修改的要求不能及时满足,使得用户不满意；
（ 2） 维护时产生的改动,可能会带来新的潜伏的故障,
从而降低了软件的整体质量；
（ 3） 当必须把软件开发人员抽调去进行维护工作时,
将在开发过程中造成混乱 。
9.2.2 维护成本用于软件维护的工作量可以分为两部分：一部分用于生产性活动,另一部分用于非生产性活动 。 下面的表达式是由 Belady和 Lehman提出的维护工作量的计算模型：
M＝ p＋ K× e(c – d)
M：维护中消耗的总工作量；
p：生产性工作量；
K：经验常数；
c：复杂程度；
d：维护人员对软件的熟悉程度。
通过这个模型可以看出，如果使用了不好的软件开发方法，参加维护的人员都不是原来开发的人员，那么维护工作量（及成本）将按指数级增加。
（ 1） 理解他人编写的程序一般都有一定的困难性 。
（ 2） 软件配置的文档严重不足甚至没有,或者没有合格的文档 。
（ 3） 当需要对软件进行维护时,由于软件人员经常流动,维护阶段持续的时间又很长,所以一般不能指望由原来的开发人员来完成或提供软件的解释 。
（ 4） 绝大多数软件在设计时没有考虑到将来的修改问题 。
（ 5） 软件维护可以说是一项毫无吸引力的工作 。 之所以形成这样一种观念,一方面是因为软件维护工作量大,
看不到什么,成果,,更主要的原因是因为维护工作难度大,又经常遭受挫折 。
9.2.3 维护的问题
9.3 软件维护过程
9.3.1 维护机构
9.3.2 维护申请报告退出
9.3.3 维护的工作流程
9.3.4 维护记录
9.3.5 维护评价
9.3.1 维护机构系统管理员维护要求
维护管理员修改负责人软件系统维护管理员负责接受维护申请,然后把维护申请交给某个系统管理员去评价 。
系统管理员是一名技术人员,他必须熟悉软件产品的某一部分 。
系统管理员对维护申请做出评价,
然后交与修改负责人确定如何进行修改 。
9.3.2 维护申请报告维护申请报告是由软件组织外部提交的文档,
它是计划维护活动的基础 。 软件组织内部应依此制定相应的软件修改报告,这个报告包括以下内容：
（ 1） 为满足某个维护申请要求所需的工作量；
（ 2） 所需修改变动的性质；
（ 3） 申请修改的优先级；
（ 4） 与修改有关的事后数据 。
软件修改报告应提交修改负责人进行审核批准,
以便进行下一步工作 。
9.3.3 维护的工作流程评价错误严重程度改正性确定类型维护要求评价优先次序完善性或适应性开始问题分析严重不严重安排改正性维护错误改正目录开始分析维护任务复审开发目录低 高人员安排修改后的软件通过后交付使用的软件人员安排无论是哪一种类型的维护,都要进行以下工作：
（ 1）修改软件设计；
（ 2）设计复审；
（ 3）对源代码的必要修改；
（ 4）单元测试；
（ 5）集成测试，包括回归测试；
（ 6）验收测试；
（ 7）软件配置复审。
在每次软件维护任务完成后，需要进行必要的情况评审。
这种评审是对以下问题的一个小结：
（ 1）在当前情况下，设计、编码、测试中的哪些方面能够改进？
（ 2）哪些维护资源是应该有而实际上却没有的？
（ 3）工作中的主要和次要的障碍是什么？
（ 4）要求的维护类型中有预防性维护吗？
9.3.4 维护记录对于维护记录中的内容,Swanson给出了下述的项目表：
（ 1） 程序名称；
（ 2） 源程序语句条数；
（ 3） 机器代码指令条数；
（ 4） 使用的程序设计语言；
（ 5） 程序的安装日期；
（ 6） 程序安装后的运行次数；
（ 7） 与程序安装后运行次数有关的处理故障的次数；
（ 8） 程序修改的层次和名称；
（ 9）由于程序修改而增加的源程序语句条数；
（ 10）由于程序修改而删除的源程序语句条数；
（ 11）每项修改所付出的“人时”数；
（ 12）程序修改的日期；
（ 13）软件维护人员的姓名；
（ 14）维护申请报告的名称；
（ 15）维护类型；
（ 16）维护开始时间和维护结束时间；
（ 17）用于维护的累计“人时”数；
（ 18）维护工作的净收益。
9.3.5 维护评价一般来说,可以从以下七个方面来评价维护工作：
（ 1） 每次程序运行时的平均出错次数；
（ 2） 用于每一类维护活动的总,人时,数；
（ 3） 每个程序,每种语言,每种维护类型所做的平均修改数；
（ 4） 维护过程中,增加或删除每条源程序语句花费的平均,人时,数；
（ 5） 用于每种语言的平均,人时,数；
（ 6） 一张维护申请报告的平均处理时间；
（ 7） 各类维护类型所占的百分比 。
9.4 软件可维护性
9.4.1 软件可维护性的度量
9.4.2 提高软件可维护性的方法退出可以从以下四个方面来度是软件的可维护性：
1,可理解性
2,可测试性
3,可修改性
4,可移植性
9.4.1 软件可维护性的度量
9.4.2 提高软件可维护性的方法
1,建立明确的软件质量标准
2,利用先进的软件技术和工具
3,建立明确的质量保证制度
4,选择可维护的程序设计语言
5,改进软件的文档
9.5 软件维护的副作用
（ 1） 对子程序的删除或修改；
（ 2） 对语句标号的删除或修改；
（ 3） 对标识符的删除或修改；
（ 4） 为改进程序执行性能所做的修改：
（ 5） 改变文件的打开或关闭；
（ 6） 对逻辑运算符的修改；
（ 7） 把设计的修改翻译成程序代码的修改；
（ 8） 对判定的边界条件所做的修改 。
为确保编码修改没有引入新的错误,应进行严格的回归测试 。 一般情况下,通过回归测试,可以发现并纠正修改编码所带来的副作用 。
1、修改编码的副作用
（ 1） 重新定义局部常量或全程常量；
（ 2） 重新定义记录格式或文件格式；
（ 3） 改变一个数组或高阶数据结构的大小；
（ 4） 修改全程变量；
（ 5） 重新初始化控制标记或指针；
（ 6） 重新排列输入输出或子程序的自变量 。
修改数据的副作用可以通过完善的设计文档来加以限制 。 这种文档描述了数据结构,并且提供了一种把数据元素,记录,文件及其它结构与软件模块联系起来的交叉对照功能 。
2、修改数据的副作用维护应该着眼于整个软件配置,而不只是源程序代码的修改 。 如果源代码的修改没有反映在设计文档或用户文档中时,就会发生文档的副作用 。
每当对数据流图,软件结构,模块算法过程和其它有关的特征进行修改时,必须同时对相应的文档资料进行更新 。
在软件再次交付使用之前,对整个软件配置进行评审将大大减少文档的副作用 。 实际上,某些维护申请的提出只是由于用户文档不够清楚 。 这时,只需对文档进行维护即可,并不要求修改软件设计或源程序 。
3、修改文档的副作用
9.3 软件维护过程
9.4 软件可维护性
9.5 软件维护的副作用退出第九章 软件维护
9.1 软件维护的概念
9.1 软件维护的概念
9.1.1 软件维护的种类
9.1.2 影响维护工作量的因素退出一般来说,要求进行维护的原因大致有以下几种：
（ 1） 改正程序中的错误和缺陷 。
（ 2） 改进设计以适应新的软,硬件环境 。
（ 3） 增加新的应用范围 。
综合以上几种要求进行维护的原因,我们可以把软件维护分为以下几类：
1,改正性维护
2,适应性维护
3,完善性维护
4,预防性维护
9.1.1 软件维护的种类
9.1.2 影响维护工作量的因素
1．系统的规模
2．系统的年龄
3．系统的结构
4．程序设计语言
5．文档的质量
9,2 软件维护的特点
9.2.1 软件工程与软件维护的关系
9.2.2 维护成本退出
9.2.3 维护的成本
9.2.1 软件工程与软件维护的关系配置评价设计计划途径修改设计重新编码评价代码
？
复查重新编码复查维护要求交付使用软件 代码无形的维护成本：
（ 1） 一些看起来是合理的改错或修改的要求不能及时满足,使得用户不满意；
（ 2） 维护时产生的改动,可能会带来新的潜伏的故障,
从而降低了软件的整体质量；
（ 3） 当必须把软件开发人员抽调去进行维护工作时,
将在开发过程中造成混乱 。
9.2.2 维护成本用于软件维护的工作量可以分为两部分：一部分用于生产性活动,另一部分用于非生产性活动 。 下面的表达式是由 Belady和 Lehman提出的维护工作量的计算模型：
M＝ p＋ K× e(c – d)
M：维护中消耗的总工作量；
p：生产性工作量；
K：经验常数；
c：复杂程度；
d：维护人员对软件的熟悉程度。
通过这个模型可以看出，如果使用了不好的软件开发方法，参加维护的人员都不是原来开发的人员，那么维护工作量（及成本）将按指数级增加。
（ 1） 理解他人编写的程序一般都有一定的困难性 。
（ 2） 软件配置的文档严重不足甚至没有,或者没有合格的文档 。
（ 3） 当需要对软件进行维护时,由于软件人员经常流动,维护阶段持续的时间又很长,所以一般不能指望由原来的开发人员来完成或提供软件的解释 。
（ 4） 绝大多数软件在设计时没有考虑到将来的修改问题 。
（ 5） 软件维护可以说是一项毫无吸引力的工作 。 之所以形成这样一种观念,一方面是因为软件维护工作量大,
看不到什么,成果,,更主要的原因是因为维护工作难度大,又经常遭受挫折 。
9.2.3 维护的问题
9.3 软件维护过程
9.3.1 维护机构
9.3.2 维护申请报告退出
9.3.3 维护的工作流程
9.3.4 维护记录
9.3.5 维护评价
9.3.1 维护机构系统管理员维护要求
维护管理员修改负责人软件系统维护管理员负责接受维护申请,然后把维护申请交给某个系统管理员去评价 。
系统管理员是一名技术人员,他必须熟悉软件产品的某一部分 。
系统管理员对维护申请做出评价,
然后交与修改负责人确定如何进行修改 。
9.3.2 维护申请报告维护申请报告是由软件组织外部提交的文档,
它是计划维护活动的基础 。 软件组织内部应依此制定相应的软件修改报告,这个报告包括以下内容：
（ 1） 为满足某个维护申请要求所需的工作量；
（ 2） 所需修改变动的性质；
（ 3） 申请修改的优先级；
（ 4） 与修改有关的事后数据 。
软件修改报告应提交修改负责人进行审核批准,
以便进行下一步工作 。
9.3.3 维护的工作流程评价错误严重程度改正性确定类型维护要求评价优先次序完善性或适应性开始问题分析严重不严重安排改正性维护错误改正目录开始分析维护任务复审开发目录低 高人员安排修改后的软件通过后交付使用的软件人员安排无论是哪一种类型的维护,都要进行以下工作：
（ 1）修改软件设计；
（ 2）设计复审；
（ 3）对源代码的必要修改；
（ 4）单元测试；
（ 5）集成测试，包括回归测试；
（ 6）验收测试；
（ 7）软件配置复审。
在每次软件维护任务完成后，需要进行必要的情况评审。
这种评审是对以下问题的一个小结：
（ 1）在当前情况下，设计、编码、测试中的哪些方面能够改进？
（ 2）哪些维护资源是应该有而实际上却没有的？
（ 3）工作中的主要和次要的障碍是什么？
（ 4）要求的维护类型中有预防性维护吗？
9.3.4 维护记录对于维护记录中的内容,Swanson给出了下述的项目表：
（ 1） 程序名称；
（ 2） 源程序语句条数；
（ 3） 机器代码指令条数；
（ 4） 使用的程序设计语言；
（ 5） 程序的安装日期；
（ 6） 程序安装后的运行次数；
（ 7） 与程序安装后运行次数有关的处理故障的次数；
（ 8） 程序修改的层次和名称；
（ 9）由于程序修改而增加的源程序语句条数；
（ 10）由于程序修改而删除的源程序语句条数；
（ 11）每项修改所付出的“人时”数；
（ 12）程序修改的日期；
（ 13）软件维护人员的姓名；
（ 14）维护申请报告的名称；
（ 15）维护类型；
（ 16）维护开始时间和维护结束时间；
（ 17）用于维护的累计“人时”数；
（ 18）维护工作的净收益。
9.3.5 维护评价一般来说,可以从以下七个方面来评价维护工作：
（ 1） 每次程序运行时的平均出错次数；
（ 2） 用于每一类维护活动的总,人时,数；
（ 3） 每个程序,每种语言,每种维护类型所做的平均修改数；
（ 4） 维护过程中,增加或删除每条源程序语句花费的平均,人时,数；
（ 5） 用于每种语言的平均,人时,数；
（ 6） 一张维护申请报告的平均处理时间；
（ 7） 各类维护类型所占的百分比 。
9.4 软件可维护性
9.4.1 软件可维护性的度量
9.4.2 提高软件可维护性的方法退出可以从以下四个方面来度是软件的可维护性：
1,可理解性
2,可测试性
3,可修改性
4,可移植性
9.4.1 软件可维护性的度量
9.4.2 提高软件可维护性的方法
1,建立明确的软件质量标准
2,利用先进的软件技术和工具
3,建立明确的质量保证制度
4,选择可维护的程序设计语言
5,改进软件的文档
9.5 软件维护的副作用
（ 1） 对子程序的删除或修改；
（ 2） 对语句标号的删除或修改；
（ 3） 对标识符的删除或修改；
（ 4） 为改进程序执行性能所做的修改：
（ 5） 改变文件的打开或关闭；
（ 6） 对逻辑运算符的修改；
（ 7） 把设计的修改翻译成程序代码的修改；
（ 8） 对判定的边界条件所做的修改 。
为确保编码修改没有引入新的错误,应进行严格的回归测试 。 一般情况下,通过回归测试,可以发现并纠正修改编码所带来的副作用 。
1、修改编码的副作用
（ 1） 重新定义局部常量或全程常量；
（ 2） 重新定义记录格式或文件格式；
（ 3） 改变一个数组或高阶数据结构的大小；
（ 4） 修改全程变量；
（ 5） 重新初始化控制标记或指针；
（ 6） 重新排列输入输出或子程序的自变量 。
修改数据的副作用可以通过完善的设计文档来加以限制 。 这种文档描述了数据结构,并且提供了一种把数据元素,记录,文件及其它结构与软件模块联系起来的交叉对照功能 。
2、修改数据的副作用维护应该着眼于整个软件配置,而不只是源程序代码的修改 。 如果源代码的修改没有反映在设计文档或用户文档中时,就会发生文档的副作用 。
每当对数据流图,软件结构,模块算法过程和其它有关的特征进行修改时,必须同时对相应的文档资料进行更新 。
在软件再次交付使用之前,对整个软件配置进行评审将大大减少文档的副作用 。 实际上,某些维护申请的提出只是由于用户文档不够清楚 。 这时,只需对文档进行维护即可,并不要求修改软件设计或源程序 。
3、修改文档的副作用
