? 软件维护的概念
? 软件维护活动
? 程序修改的步骤及修改
的副作用
? 可维护性
? 提高可维护性的方法
软件维护的概念
? 软件维护的定义
? 影响维护工作量的因素
? 软件维护的策略
? 维护成本
软件维护的定义
? 在软件运行／维护阶段 对软件产品
进行的修改 就是所谓的维护。
? 维护的类型有三种：
? 改正性维护
? 适应性维护
? 完善性维护
改正性维护
? 在软件交付使用后，因开发时测试
的 不彻底, 不完全,必然会有部分
隐藏的错误遗留到运行阶段。
? 这些隐藏下来的错误 在某些特定的
使用环境下就会暴露出来 。
? 为了 识别和纠正软件错误, 改正软
件性能上的缺陷, 排除实施中的误
使用,应当进行的诊断和改正错误
的过程就叫做改正性维护。
适应性维护
? 在使用过程中，
? 外部环境 （ 新的硬、软件配臵 ）
? 数据环境 （ 数据库、数据格式、
数据输入 /输出方式、数据存储介
质 ）
可能发生变化。
? 为使软件适应这种变化，而去修改
软件的过程就叫做适应性维护。
完善性维护
? 在软件的使用过程中，用户往往会
对软件提出新的 功能 与 性能 要求。
? 为了满足这些要求，需要修改或再
开发软件，以 扩充软件功能, 增强
软件性能, 改进加工效率, 提高软
件的可维护性 。
? 这种情况下进行的维护活动叫做完
善性维护。
? 实践表明，在几种维护活动中，完
善性维护所占的比重最大。 即大部
分维护工作是改变和加强软件，而
不是纠错 。
? 完善性维护不一定是救火式的紧急
维修，而可以 是有计划、有预谋的
一种再开发活动 。
? 事实证明，来自用户要求扩充、加
强软件功能、性能的维护活动约占
整个维护工作的 50％。
预防性维护
? 预防性维护是为了 提高软件的可维
护性, 可靠性等,为以后进一步改
进软件打下良好基础。
? 预防性维护定义为,采用先进的软
件工程方法对需要维护的软件或软
件中的某一部分（重新）进行设计、
编制和测试。
? 在整个软件维护阶段所花费的全部
工作量中,完善性维护占了几乎一
半的工作量。
? 软件维护活动所花费的工作占整个
生存期工作量的 70%以上,这是由
于在漫长的软件运行过程中需要不
断对软件进行修改，以 改正新发现
的错误,适应新的环境和用户新的
要求，这些修改需要花费很多精力
和时间，而且有时会引入新的错误。
维护在软件生 三类维护占
存期所占比例 总维护比例
影响维护工作量的因素
? 在软件的维护过程中，需要花费
大量的工作量，从而直 接影响了
软件维护的成本 。
? 应当考虑 有哪些因素影响软件维
护的工作量,相应 应该采取什么
维护策略,才能 有效地维护软件
并 控制维护的成本 。
? 系统大小,系统越大，理解掌握
起来越困难。系统越大，所执行
功能越复杂。因而需要更多的维
护工作量。
? 程序设计语言,使用强功能的程
序设计语言可以控制程序的规模。
语言的功能越强，生成程序的模
块化和结构化程度越高，所需的
指令数就越少，程序的可读性越
好。
? 系统年龄,
? 老系统随着不断的修改，结构越
来越乱；
? 维护人员经常更换，程序又变得
越来越难于理解。
? 许多老系统在当初并未按照软件
工程的要求进行开发，因而没有
文档，或文档太少。
? 在长期的维护过程中文档在许多
地方与程序实现变得不一致，在
维护时就会遇到很大困难。
? 数据库技术的应用,使用数据库，
可以简单而有效地管理和存储用户
程序中的数据，还可以减少生成用
户报表应用软件的维护工作量。
? 先进的软件开发技术,在软件开发
时，若使用能使软件结构比较稳定
的分析与设计技术，及程序设计技
术，如面向对象技术、复用技术等，
可减少大量的工作量。
? 其它,
? 应用的类型
? 数学模型
? 任务的难度
? 开关与标记,IF嵌套深度、索引
或下标数等
对维护工作量都有影响。
? 许多软件在开发时并未考虑将来的
修改，为软件的维护带来许多问题。
软件维护的策略
? 改正性维护
通常要生成 100％可靠的软件并不
一定合算，成本太高 。 但通过使用
新技术，可大大减少进行改正性维
护的需要 。
这些技术包括,数据库管理系统,
软件开发环境, 程序自动生成系统,
较高级 (第四代 )的语言 。 以及 新的
开发方法, 软件复用, 防错程序设
计 及 周期性维护审查 等 。
? 适应性维护
这一类维护不可避免，可以控制。
(1) 在配臵管理时，把硬件、操作
系统和其它相关环境因素的可能变
化考虑在内 。
(2) 把与硬件、操作系统，以及其
它外围设备有关的程序归到特定的
程序模块中。
(3) 使用内部程序列表、外部文件，
以及处理的例行程序包，可为维护
时修改程序提供方便。
? 完善性维护
利用前两类维护中列举的方法，也
可以减少这一类维护。特别是 数据
库管理系统, 程序生成器, 应用软
件包,可减少维护工作量。
此外，建立软件系统的原型，把它
在实际系统开发之前提供给用户。
用户通过研究原型，进一步完善他
们的功能要求，就可以减少以后完
善性维护的需要。
维护成本
? 有形的软件维护成本 是花费了多少
钱,无形的维护成本 有更大的影响。
? 一些 合理的修复或修改请求不能
及时安排,使得客户不满意；
? 变更的结果 引入新的故障,使得
软件整体质量下降；
? 把软件人员抽调到维护工作中，
干扰了软件开发工作。
? 软件维护的 代价 是 降低了生产率,
在做老程序的维护时非常明显。
? 例如,开发每一行源代码耗资 25美
元, 维护每一行源代码需要耗资
1000美元 。
? 维护工作量包括 生产性活动 （如分
析和评价、设计修改和实现）和
“轮转”活动 （如力图理解代码在
做什么、试图判明数据结构、接口
特性、性能界限等）。
维护工作量的模型
? M是维护中消耗的总工作量
? p是上面描述的生产性工作量
? K是一个经验常数
? c是因缺乏好的设计和文档而导致
复杂性的度量
? d是对软件熟悉程度的度量。
dcKepM ???
? 模型指明，如果使用了不好的软件
开发方法（未按软件工程要求做），
原来参加开发的人员或小组不能参
加维护，则工作量（及成本）将按
指数级增加。
软件维护活动
? 为了有效地进行软件维护，应事先
就开始做组织工作。
? 首先 建立维护的机构
? 申明 提出维护申请报告的过程 及
评价的过程
? 为每一个维护申请规定 标准的处
理步骤
? 建立 维护活动的登记制度 以及规
定 评价和评审的标准 。
维护机构
? 除了较大的软件开发公司外，通常
在软件维护工作方面，并不保持一
个正式的组织机构。
? 虽然不要求建立一个正式的维护机
构，但是在开发部门确立一个非正
式的维护机构则是非常必要的。
软件维护的机构
? 维护申请 提交给 维护管理员,他把
申请交给某个 系统监督员 去 评价 。
? 一旦做出评价，由 修改负责人 确定
如何进行修改 。
? 在修改程序的过程中，由 配臵管理
员 严格把关,控制修改的范围, 对
软件配臵进行审计 。
? 在维护之前，就把责任明确下来，
可以减少维护过程中的混乱。
软件维护申请报告
? 维护申请报告或称 软件问题报告,
由 申请维护的用户 填写 。
? 用户必须 完整地说明产生错误的情
况,包括 输入数据, 错误清单 以及
其它有关材料 。
? 如果申请的是适应性维护或完善性
维护，用户必须提出一份修改说明
书，列出所有希望的修改。
? 维护申请报告将由 维护管理员 和
系统监督员 来研究处理。
? 他们应相应地做出 软件修改报告,
指明：
? 所需修改变动的性质；
? 申请修改的优先级；
? 为满足某个维护申请报告，所
需的工作量；
? 预计修改后的状况,
? 软件修改报告应提交修改负责人，
经批准后才能开始进一步安排维
护工作。
软件维护
工作流程
? 尽管维护申请的类型不同，但都要
进行同样的技术工作。
? 修改软件需求说明
? 修改软件设计
? 设计评审
? 对源程序做必要的修改
? 单元测试
? 集成测试 ( 回归测试 )
? 确认测试
? 软件配臵评审等 。
在每次软件维护任务完成后进行情况
评审，对以下问题做一总结：
(1) 在目前情况下，设计、编码、测
试中的哪一方面可以改进?
(2) 哪些维护资源应该有但没有?
(3) 工作中主要的或次要的障碍是什
么?
(4) 从维护申请的类型来看是否应当
有预防性维护?
情况评审对将来的维护工作如何进行
会产生重要的影响。
维护档案记录
? 程序名称
? 源程序语句条数
? 机器代码指令条数
? 所用的程序设计语言
? 程序安装的日期
? 程序安装后的运行次数
? 与程序安装后运行次数有关的处
理故障次数
? 程序改变的层次及名称
? 修改程序增加的源程序语句条数
? 修改程序减少的源程序语句条数
? 每次修改所付出的“人时”数
? 修改程序的日期
? 软件维护人员的姓名
? 维护申请报告的名称、维护类型
? 维护开始时间和维护结束时间、
? 花费在维护上的累计“人时”数
? 维护工作的净收益等。
维护评价
? 评价维护活动比较困难,因为缺
乏可靠的数据。
? 如果维护的档案记录做得比较好，
可以得出一些维护“性能”方面
的度量值。
? 每次程序运行时的平均出错次数；
? 花费在每类维护上的总“人时”
数；
? 每个程序、每种语言、每种维
护类型的程序平均修改次数；
? 因为维护，增加或删除每个源
程序语句所花费的平均“人时”
数；
? 用于每种语言的平均“人时”
数；
? 维护申请报告的平均处理时间；
? 各类维护申请的百分比。
据此可对开发技术、语言选择、
维护工作计划、资源分配、以
及其它许多方面做出判定。
程序修改的步骤及修改的副作用
? 在软件维护时，必然会对源程序进
行修改。
? 通常对源程序的修改不能无计划地
仓促上阵，为了正确、有效地修改,
需要经历以下三个步骤。
? 分析和理解程序
? 修改程序
? 重新验证程序
分析和理解程序
? 经过分析,全面、准确、迅速地理
解程序是决定维护成败和质量好坏
的关键 。在这方面，软件的可理解
性和文档的质量非常重要。
? 理解程序的功能和目标；
? 掌握程序的结构信息，即从程序
中细分出若干结构成分。如程序
系统结构,控制结构、数据结构
和输入／输出结构等；
? 了解数据流信息，即涉及到的数
据来源何处，在哪里被使用；
? 了解控制流信息，即执行每条路
径的结果；
? 理解程序的操作 (使用 )要求；
? 为了容易地理解程序，要求自顶向
下地理解现有源程序的程序结构和
数据结构，为此可采用如下几种方
法：
1,分析程序结构图
(1) 搜集所有存储该程序的文件，
阅读这些文件，记下它们包含的过
程名,建立一个包括这些过程名和
文件名的清单 ；
(2) 分析各个过程的源代码,建立
一个直接调用矩阵 D或调用树 。若
过程 i 调用过程 j，则 D[i][j]＝ 1，
否则 D[i][j]＝ 0。
(3) 建立过程的间接调用矩阵 I，
即直接调用矩阵 D的传递闭包
I＝ D1∪ D2∪ D3∪ … ∪ Dn
其中,n是所包含的过程总数,
例如，过程 i 调用 j,j 调用 k，
则 D[i][j]＝ 1,D[j][k]＝ 1，
I[i][k]＝ 1。
(4) 分析各个过程的接口, 估计更
改的复杂性 。
2,数据跟踪
(1) 建立各层次的程序级上的接口
图,展示各模块或过程的调用方式
和接口参数；
(2) 利用数据流分析方法，对过程
内部的一些变量进行跟踪。 可获得
有关数据在过程间如何传递, 在过
程内如何处理 等信息。对于判断问
题原因特别有用。在跟踪的过程中
可在源程序中间插入自己的注释。
3,控制跟踪
控制流跟踪可采用符号执行或实际
动态跟踪的方法,了解数据如何从
一个输入源到达输出点的 。
4,充分阅读和使用源程序清单和文档,
分析现有文档的合理性。
5,充分使用由编译程序或汇编程序提
供的交叉引用表、符号表、以及其
它有用的信息。
6,如有可能，积极参加开发工作。
修改程序
? 对程序的修改，必须事先做出计划，
有预谋地、周密有效地实施修改。
1,设计程序的修改计划
程序的修改计划要考虑人员和资源
的安排。小的修改可以不需要详细
的计划，而对于需要耗时数月的修
改，就需要计划立案。
在编写有关问题解决的方案时，必
须充分描述修改作业的规格说明。
?规格说明信息：数据修改、处
理修改、作业控制语言修改、系统
之间接口的修改等；
?维护资源：新程序版本、测试
数据、所需软件、计算机时间等；
?人员；
?支持,纸面、计算机媒体等。
通常，可采用自顶向下的方法，在
理解程序的基础上，
(1) 研究程序的各个模块、模块的接
口、及数据库,从全局的观点，提
出修改计划。
(2) 依次地把 要修改的,以及 那些受
修改影响的模块和数据结构 分离出
来 。为此，要
?识别受修改影响的数据；
?识别使用这些数据的程序模块；
?对于上面程序模块，按是产生
数据、修改数据、还是删除数据
进行分类；
?识别对这些数据元素的外部控
制信息；
?识别编辑和检查这些数据元素
的地方；
?隔离要修改的部分；
(3) 详细地分析 要修改的,以及 那些
受变更影响的模块和数据结构 的内
部细节,设计修改计划,标明新逻
辑及要改动的现有逻辑。
(4) 向用户提供 回避措施 。用户的某
些业务因软件中发生问题而中断，
为不让系统长时间停止运行，需把
问题局部化,在可能的范围内继续
开展业务 。
可以采取的措施有：
① 查找问题原因,可能情况有：
?意外停机
?安装的期限到期
?系统运行中发现错误
② 如果弄清了问题的原因，可 通过
临时修改或改变运行控制以回避在
系统运行时产生的问题 。
2,修改代码，以适应变化
在修改时，要求：
(1) 正确、有效地编写修改代码；
(2) 要谨慎地修改程序，尽量保持
程序的风格及格式，要在程序清
单上注明改动的指令；
(3) 不要删除程序语句，除非完全
肯定它是无用的；
(4) 不要试图共用程序中已有的临
时变量或工作区，为了避免冲突
或混淆用途，应设臵自己的变量；
(5) 插入错误检测语句；
(6) 在修改过程中做好修改的详细
记录，消除变更中任何有害的副作
用（波动效应）；
3,修改程序的副作用
所谓副作用是指因修改软件而造成
的错误或其它不希望发生的情况。
副作用有三种,修改代码的副作用,
修改数据的副作用, 文档的副作用 。
? 在修改源代码时，都可能引入错误。
例如,删除或修改一个子程序, 删
除或修改一个标号, 删除或修改一
个标识符, 改变程序代码的时序关
系, 改变占用存储的大小, 改变逻
辑运算符, 修改文件的打开或关闭,
改进程序的执行效率,以及 把设计
上的改变翻译成代码的改变 时，都
容易引入错误。
(1) 修改代码的副作用
(2) 修改数据的副作用
? 在 修改数据结构 时，有可能造成 软
件设计与数据结构不匹配,因而导
致软件出错。
? 数据副作用就是修改软件信息结构
导致的结果。
? 容易导致设计与数据不相容的错误
可以有：
? 重新定义局部的或全局的常量
? 重新定义记录或文件的格式
? 增大或减小一个数组或高层数据
结构的大小
? 修改全局或公共数据
? 重新初始化控制标志或指针
? 重新排列输入／输出或子程序的
参数
? 数据副作用可以通过 交叉引用表 加
以控制。把数据元素、记录、文件
和其它结构联系起来。
(3) 文档的副作用
? 对 数据流, 软件结构, 模块逻辑 或
任何其它有关特性 进行修改时，必
须 对相关技术文档进行相应修改 。
否则会导致 文档与程序功能不匹配,
缺省条件改变, 新错误信息不正确
等错误。使得 软件文档不能反映软
件的当前状态 。
? 对于用户来说，软件事实上就是文
档。
? 如果对可执行软件的修改不反映在
文档里，就会产生文档的副作用。
? 对交互输入的顺序或格式进行修
改，如果没有正确地记入文档中，
就可能引起重大的问题。
? 过时的文档内容、索引和文本可
能造成冲突，引起用户失败和不
满。
? 因此,必须在软件交付之前对整个
软件配臵进行评审,以减少文档的
副作用。
? 为了控制因修改而引起的副作用，
要做到：
(1) 按模块把修改分组；
(2) 自顶向下地安排被修改模块的
顺序；
(3) 每次修改一个模块；
(4) 对于每个修改了的模块，在安
排修改下一个模块之前，要确定这
个修改的副作用。 可以使用交叉引
用表、存储映象表、执行流程跟踪
等。
重新验证程序
? 在将修改后的程序提交用户之前，
需要进行 充分的确认和测试,以
保证整个修改后程序的正确性。
? 静态确认
修改软件，伴随着引起新的错误
的危险 。为了能够做出正确的判
断，验证修改后的程序至少需要
两个人参加。要检查：
(1) 修改是否涉及到规格说明? 修
改结果是否符合规格说明? 有没有
歪曲规格说明?
(2) 程序的修改是否足以修正软件
中的问题? 源程序代码有无逻辑错
误? 修改时有无修补失误?
(3) 修改部分对其它部分有无不良
影响 (副作用 )?
对软件进行修改，常常会引发别的
问题，有必要检查修改的影响范围 。
? 计算机确认
在进行了以上确认的基础上，用计
算机对修改程序进行确认测试：
(1) 确认测试顺序,先对修改部分
进行测试，然后隔离修改部分，测
试程序的未修改部分，最后再把它
们集成起来进行测试。这种测试称
为回归测试。
(2) 准备标准的测试用例 。
(3) 充分利用软件工具帮助重新验
证过程 。
(4) 在重新确认过程中，需邀请用
户参加 。
? 维护后的验收 ──在交付新软件之
前，维护主管部门要检验：
(1) 全部文档是否完备，并已更新；
(2) 所有测试用例和测试结果已经
正确记载；
(3) 记录软件配臵所有副本的工作
已经完成；
(4) 维护工序和责任已经确定。
从维护角度来看所需测试种类
(1) 对 修改事务 的测试；
(2) 对 修改程序 的测试；
(3) 操作过程 的测试；
(4) 应用系统运用过程 的测试；
(5) 系统各部分之间接口 的测试；
(6) 作业控制语言 的测试；
(7) 与系统软件接口 的测试；
(8) 软件系统之间接口 的测试；
(9) 安全性 测试；
(10) 后备／恢复过程 的测试。
软件可维护性
? 许多软件的维护十分困难，原因在
于这 些软件的文档不全, 质量差,
开发过程不注意采用好的方法, 忽
视程序设计风格 等。
? 许多维护要求并不是因为程序中出
错而提出的，而是为 适应环境变化
或 需求变化 而提出的。
? 为了使得软件能够易于维护，必须
考虑使软件具有 可维护性 。
软件可维护性的定义
? 软件可维护性 是指 纠正软件系统出
现的错误和缺陷，以及为满足新的
要求进行修改、扩充或压缩的容易
程度 。
? 可维护性, 可使用性, 可靠性 是衡
量软件质量的主要质量特性，也是
用户十分关心的几个方面。
? 软件的 可维护性 是 软件开发阶段各
个时期的关键目标 。
? 目前广泛使用的是用如下的七个特
性来衡量程序的可维护性。
可理解性 可使用性
可测试性 可移植性
可修改性 效率
可靠性
? 而且对于不同类型的维护，这七种
特性的侧重点也不相同 。
在各类维护中的侧重点
改改 正正 性性 维维 护护 适适 应应 性性 维维 护护 完完 善善 性性 维维 护护
可可 理理 解解 性性 ??
可可 测测 试试 性性 ??
可可 修修 改改 性性 ?? ??
可可 靠靠 性性 ??
可可 移移 植植 性性 ??
可可 使使 用用 性性 ?? ??
效效 率率 ??
? 这些质量特性通常体现在软件产品
的许多方面 ;
? 为使每一个质量特性都达到预定的
要求，需要在软件开发的各个阶段
采取相应的措施加以保证。
? 这些质量要求要渗透到而各开发阶
段的各个步骤当中 。因此，软件的
可维护性是产品投入运行以前各阶
段面向上述各质量特性要求进行开
发的最终结果。
可维护性的度量
? 人们一直期望 对软件的可维护性做
出定量度量,但要做到这一点并不
容易。
? 常用的度量一个可维护的程序的七
种特性的方法。就是
? 质量检查表
? 质量测试
? 质量标准
? 质量检查表 是用于测试程序中某些
质量特性是否存在的一个问题清单。
? 评价者针对检查表上的每一个问题，
依据自己的定性判断，回答,Yes”
或者,No”。
? 质量测试 与 质量标准 则用于定量分
析和评价程序的质量。
? 由于许多质量特性是相互抵触的，
要 考虑几种不同的度量标准,相应
地去度量不同的质量特性。
1,可理解性
? 可理解性表明人们通过阅读源代码
和相关文档，了解程序功能及其如
何运行的容易程度。
? 一个可理解的程序应具备以下一些
特性,模块化, 风格一致性, 不使
用令人捉摸不定或含糊不清的代码,
使用有意义的数据名和过程名, 结
构化, 完整性 等。
2,可靠性
? 可靠性表明一个程序按照用户的要
求和设计目标，在给定的一段时间
内正确执行的概率。
? 关于可靠性，度量的标准主要有：
? 平均失效间隔时间 MTTF
? 平均修复时间 MTTR
? 有效性 A = MTBD/(MTBD+MDT)
度量可靠性的方法
? 根据程序错误统计数字，进行可靠
性预测 。常用方法是利用一些 可靠性
模型, 根据程序测试时发现并排除的
错误数预测平均失效间隔时间 MTTF。
? 根据程序复杂性，预测软件可靠性 。
用程序复杂性预测可靠性,前提条件
是可靠性与复杂性有关 。因此可用复
杂性预测出错率。程序复杂性度量标
准可用于 预测哪些模块最可能发生错
误,以及 可能出现的错误类型 。
3,可测试性
? 可测试性表明论证程序正确性的容
易程度 。程序越简单，证明其正确
性就越容易。而且设计合用的测试
用例，取决于对程序的全面理解。
? 一个可测试的程序应当是 可理解的,
可靠的, 简单的 。
? 用于可测试性度量的检查项目如下：
? 程序是否模块化? 结构是否良好?
? 程序是否可理解? 程序是否可靠?
? 程序是否能显示任意中间结果?
? 程序是否能以清楚的方式描述它的
输出?
? 程序是否能及时地按照要求显示所
有的输入?
? 程序是否有跟踪及显示逻辑控制流
程的能力?
? 程序是否能从检查点再启动?
? 程序是否能显示带说明的错误信息?
4,可修改性
? 可修改性表明程序容易修改的程度 。
? 一个可修改的程序应当是 可理解的,
通用的, 灵活的, 简单的 。
? 通用性是指程序适用于各种功能变
化而无需修改。
? 灵活性是指能够容易地对程序进行
修改。
? 测试可修改性的一种定量方法是
修改练习 。其基本思想是 通过做
几个简单的修改, 来评价修改的
难度 。
? 设 C是程序中各个模块的平均复杂
性,n是必须修改的模块数,A 是
要修改的模块的平均复杂性。 则
修改的难度 D由下式计算：
D = A / C
5,可移植性
? 可移植性表明程序转移到一个新的
计算环境的可能性的大小 。或者它
表明程序可以容易地、有效地在各
种各样的计算环境中运行的容易程
度。
? 一个可移植的程序应具有 结构良好,
灵活, 不依赖于某一具体计算机或
操作系统的性能 。
? 用于可移植性度量的检查项目如下：
? 是否是用高级的独立于机器的语言
来编写程序?
? 是否使用广泛使用的标准化的程序
设计语言来编写程序? 是否仅使用
了这种语言的标准版本和特性?
? 程序中是否使用了标准的普遍使用
的库功能和子程序?
? 程序中是否极少使用或根本不使用
操作系统的功能?
?程序在执行之前是否初始化内存?
? 程序在执行之前是否测定当前的
输入／输出设备?
? 程序是否把与机器相关的语句分
离了出来，集中放在了一些单独的
程序模块中，并有说明文件?
? 程序是否结构化? 并允许在小一
些的计算机上分段 (覆盖 )运行?
? 程序中是否避免了依赖于字母数
字或特殊字符的内部位表示?
6,效率
? 效率表明一个程序能执行预定功能
而又不浪费机器资源的程度 。
? 这些机器资源包括 内存容量, 外存
容量, 通道容量 和 执行时间 。
? 用于效率度量的检查项目如下,
? 程序是否模块化? 结构是否良好?
? 是否消除了无用的标号与表达式，
以充分发挥编译器优化作用?
? 程序的编译器是否有优化功能?
? 是否把特殊子程序和错误处理
子程序都归入了单独的模块中?
? 是否以快速的数学运算代替了
较慢的数学运算?
? 是否尽可能地使用了整数运算，
而不是实数运算?
? 是否在表达式中避免了混合数
据类型的使用，消除了不必要的
类型转换?
? 程序是否避免了非标准的函数或
子程序的调用?
? 在几条分支结构中，是否最有可
能为“真”的分支首先得到测试?
? 在复杂的逻辑条件中，是否最有
可能为“真“的表达式首先得到
测试?
7,可使用性
? 从用户观点出发,可使用性定义为
程序方便、实用、及易于使用的程
度 。一个可使用的程序应是 易于使
用的, 能允许用户出错和改变,并
尽可能不使用户陷入混乱状态的 程
序。
? 用于可使用性度量的检查项目如下：
? 程序是否具有自描述性?
? 程序是否能始终如一地按照用
户的要求运行?
? 程序是否让用户对数据处理有
一个满意的和适当的控制?
? 程序是否容易学会使用?
? 程序是否使用数据管理系统来
自动地处理事务性工作和管理格
式化、地址分配及存储器组织。
? 程序是否具有容错性?
? 程序是否灵活?
其它间接定量度量可维护性的方法
? 问题识别的时间；
? 因管理活动拖延的时间；
? 收集维护工具的时间；
? 分析、诊断问题的时间；
? 修改规格说明的时间；
? 具体的改错或修改的时间；
? 局部测试的时间；
? 集成或回归测试的时间；
? 维护的评审时间；
? 这些数据反映了维护全过程中 检
错－纠错－验证 的周期，即 从检
测出软件存在的问题开始至修正
它们并经回归测试验证这段时间 。
? 可以粗略地认为,这个周期越短，
维护越容易 。
提高可维护性的方法
? 建立明确的软件质量目标和
优先级
? 使用提高软件质量的技术和
工具
? 进行明确的质量保证审查
? 选择可维护的程序设计语言
? 改进程序的文档
建立明确的软件质量目标和优先级
? 一个可维护的程序应是 可理解的,
可靠的, 可测试的, 可修改的, 可
移植的, 效率高的, 可使用的 。
? 要实现这所有的目标，需要付出很
大的代价，而且也不一定行得通。
? 某些质量特性是相互促进的,例如
可理解性和可测试性、可理解性和
可修改性。
? 另一些质量特性是相互抵触的,如
效率和可移植性、效率和可修改性
等。
? 每一种 质量特性 的 相对重要性 应随
程序的用途及计算环境的不同而不
同 。例如，对编译程序来说，可能
强调效率；但对管理信息系统来说，
则可能强调可使用性和可修改性。
? 应当对程序的质量特性，在 提出目
标 的同时还必须 规定它们的优先级 。
使用提高软件质量的技术和工具
? 模块化
? 如果需要改变某个模块的功能，
则只要改变这个模块，对其它模块
影响很小；
? 如果需要增加程序的某些功能，
则仅需增加完成这些功能的新的模
块或模块层；
? 程序的测试与重复测试比较容易；
? 程序错误易于定位和纠正；
? 结构化程序设计
? 程序被划分成分层的模块结构；
? 模块调用控制必须从模块的入口
点进入，从其出口点退出。
? 模块的控制结构仅限于顺序、选
择、重复三种，且没有 GOTO语
句。
? 每个程序变量只用于唯一的程序
目的，而且变量的作用范围应是
明确的、有限制的。
? 使用结构化程序设计技术，提高现
有系统的可维护性
? 采用备用件的方法 ──用一个新的
结构良好的模块替换掉整个要修改
的模块。
? 采用自动重建结构和重新格式化
的工具 (结构更新技术 )──把非结构
化代码转换成良好结构代码 。
? 改进现有程序的不完善的文档 ─ ─
建立或补充系统说明书、设计文档、
模块说明书、以及在源程序中插入
必要的注释。
进行明确的质量保证审查
? 质量保证审查 对于 获得和维持软件
的质量,是一个很有用的技术。
? 审查 可以用来 检测在开发和维护阶
段内发生的质量变化 。
? 一旦检测出问题来，就可以采取措
施来纠正，以控制不断增长的软件
维护成本，延长软件系统的有效生
命期。
? 保证软件质量的最佳方法是 在软件
开发的最初阶段把质量要求考虑进
去,并 在开发过程每一阶段的终点,
设臵检查点进行检查 。
? 检查的目的是要证实，已开发的软
件 是否符合标准, 是否满足规定的
质量需求 。在不同的检查点，检查
的重点不完全相同。
1,在检查点进行复审
软件开发期间各个检查点的检查重点
? 在设计阶段，检查重点是 可理解性,
可修改性, 可测试性 。
? 可理解性 检查的重点是 程序的复杂
性 。对每个模块可用 McCabe环路
来计算模块的复杂性，若大于 10，
则需重新设计。
? 可以使用各种 质量特性检查表,或
用 度量标准 来检查可维护性。
? 审查小组可以采用人工测试一类的
方式，进行审查。
2,验收检查
? 验收检查 是一个 特殊的检查点 的检
查，是交付使用前的 最后一次检查,
? 验收检查 实际上是 验收测试 的一部
分，只不过它是从维护的角度提出
验收的条件和标准。
? 验收检查必须遵循的最小验收标准。
(1) 需求和规范标准
① 需求应当以可测试的术语进行
书写，排列优先次序和定义；
② 区分必须的、任选的、将来的
需求；
③ 包括对系统运行时的计算机设
备的需求；对维护、测试、操作、
以及维护人员的需求；对测试工具
等的需求。
(2) 设计标准
① 程序应设计成分层的模块结
构。每个模块应完成唯一的功能，
并达到高内聚、低耦合；
② 通过一些知道预期变化的实
例，说明设计的可扩充性、可缩减
性和可适应性。
(3) 源代码标准
① 尽可能使用最高级的程序设
计语言，且只使用语言的标准版本；
② 所有的代码都必须具有良好
的结构；
③ 所有的代码都必须文档化，
在注释中说明它的输入、输出、以
及便于测试／再测试的一些特点与
风格。
(4) 文档标准
文档中应说明
? 程序的输入／输出
? 使用的方法／算法
? 错误恢复方法
? 所有参数的范围
? 缺省条件等。
3,周期性地维护审查
? 检查点复查 和 验收检查,可用来 保
证新软件系统的可维护性 。
? 对已有的软件系统，则应当 进行周
期性的维护检查 。
? 软件在运行期间进行修改，会导致
软件质量有变坏的危险，破坏程序
概念的完整性。
? 必须 定期检查,对软件做周期性的
维护审查,以跟踪软件质量的变化 。
? 周期性维护审查 实际上是开发阶段
检查点复查的继续，并且 采用的检
查方法, 检查内容都是相同的 。
? 维护审查的结果 可以同 以前的维护
审查的结果, 以前的验收检查的结
果, 检查点检查的结果 相比较，任
何一种改变都表明在软件质量上或
其它类型的问题上可能起了变化。
? 对于改变的原因应当进行分析 。
4,对软件包进行检查
? 软件包 是一种 标准化 的，可 为不同
单位, 不同用户使用 的软件。
? 一般 源代码和程序文档 不会提供给
用户。
? 对软件包的维护采取以下方法。
? 使用单位的维护人员首先要仔细
分析、研究卖主提供的用户手册、
操作手册、培训教程等，以及卖
方提供的验收测试报告等。
? 在此基础上，深入 了解本单位的希
望和要求, 编制软件包的检验程序 。
检查软件包程序所执行的功能是否
与用户的要求和条件相一致。
? 为了建立这个程序，维护人员可以
利用卖方提供的验收测试实例,还
可以自 己重新设计新的测试实例 。
? 根据测试结果，检查和验证软件包
的参数或控制结构，以完成软件包
的维护。
选择可维护的程序设计语言
? 程序设计语言的选择，对程序的可
维护性影响很大。
机器语言 汇编语言 高级语言 查询语言
(FORTRAN,报表生成语言
COBOL等 ) 图象语言
应用生成语言
改进程序的文档
? 程序文档是对程序 总目标, 程序各
组成部分之间的关系, 程序设计策
略, 程序实现过程的历史数据 等的
说明和补充。
? 即使是一个十分简单的程序，要想
有效地、高效率地维护它，也需要
编制文档来解释其目的及任务。
? 对于程序维护人员来说，要想 按程
序编制人员的意图重新改造程序,
并对今后变化的可能性进行估计，
缺了文档是不行的。
? 因此，为了维护程序，人们必须阅
读和理解文档。
? 另外，在软件维护阶段，利用 历史
文档,可以大大简化维护工作。通
过了解原设计思想，可以判断出错
之处，指导维护人员选择适当的方
法修改代码而不危及系统的完整性。
? 历史文档有三种：
? 系统开发日志
? 错误记载
? 系统维护日志
? 软件维护活动
? 程序修改的步骤及修改
的副作用
? 可维护性
? 提高可维护性的方法
软件维护的概念
? 软件维护的定义
? 影响维护工作量的因素
? 软件维护的策略
? 维护成本
软件维护的定义
? 在软件运行／维护阶段 对软件产品
进行的修改 就是所谓的维护。
? 维护的类型有三种：
? 改正性维护
? 适应性维护
? 完善性维护
改正性维护
? 在软件交付使用后，因开发时测试
的 不彻底, 不完全,必然会有部分
隐藏的错误遗留到运行阶段。
? 这些隐藏下来的错误 在某些特定的
使用环境下就会暴露出来 。
? 为了 识别和纠正软件错误, 改正软
件性能上的缺陷, 排除实施中的误
使用,应当进行的诊断和改正错误
的过程就叫做改正性维护。
适应性维护
? 在使用过程中，
? 外部环境 （ 新的硬、软件配臵 ）
? 数据环境 （ 数据库、数据格式、
数据输入 /输出方式、数据存储介
质 ）
可能发生变化。
? 为使软件适应这种变化，而去修改
软件的过程就叫做适应性维护。
完善性维护
? 在软件的使用过程中，用户往往会
对软件提出新的 功能 与 性能 要求。
? 为了满足这些要求，需要修改或再
开发软件，以 扩充软件功能, 增强
软件性能, 改进加工效率, 提高软
件的可维护性 。
? 这种情况下进行的维护活动叫做完
善性维护。
? 实践表明，在几种维护活动中，完
善性维护所占的比重最大。 即大部
分维护工作是改变和加强软件，而
不是纠错 。
? 完善性维护不一定是救火式的紧急
维修，而可以 是有计划、有预谋的
一种再开发活动 。
? 事实证明，来自用户要求扩充、加
强软件功能、性能的维护活动约占
整个维护工作的 50％。
预防性维护
? 预防性维护是为了 提高软件的可维
护性, 可靠性等,为以后进一步改
进软件打下良好基础。
? 预防性维护定义为,采用先进的软
件工程方法对需要维护的软件或软
件中的某一部分（重新）进行设计、
编制和测试。
? 在整个软件维护阶段所花费的全部
工作量中,完善性维护占了几乎一
半的工作量。
? 软件维护活动所花费的工作占整个
生存期工作量的 70%以上,这是由
于在漫长的软件运行过程中需要不
断对软件进行修改，以 改正新发现
的错误,适应新的环境和用户新的
要求，这些修改需要花费很多精力
和时间，而且有时会引入新的错误。
维护在软件生 三类维护占
存期所占比例 总维护比例
影响维护工作量的因素
? 在软件的维护过程中，需要花费
大量的工作量，从而直 接影响了
软件维护的成本 。
? 应当考虑 有哪些因素影响软件维
护的工作量,相应 应该采取什么
维护策略,才能 有效地维护软件
并 控制维护的成本 。
? 系统大小,系统越大，理解掌握
起来越困难。系统越大，所执行
功能越复杂。因而需要更多的维
护工作量。
? 程序设计语言,使用强功能的程
序设计语言可以控制程序的规模。
语言的功能越强，生成程序的模
块化和结构化程度越高，所需的
指令数就越少，程序的可读性越
好。
? 系统年龄,
? 老系统随着不断的修改，结构越
来越乱；
? 维护人员经常更换，程序又变得
越来越难于理解。
? 许多老系统在当初并未按照软件
工程的要求进行开发，因而没有
文档，或文档太少。
? 在长期的维护过程中文档在许多
地方与程序实现变得不一致，在
维护时就会遇到很大困难。
? 数据库技术的应用,使用数据库，
可以简单而有效地管理和存储用户
程序中的数据，还可以减少生成用
户报表应用软件的维护工作量。
? 先进的软件开发技术,在软件开发
时，若使用能使软件结构比较稳定
的分析与设计技术，及程序设计技
术，如面向对象技术、复用技术等，
可减少大量的工作量。
? 其它,
? 应用的类型
? 数学模型
? 任务的难度
? 开关与标记,IF嵌套深度、索引
或下标数等
对维护工作量都有影响。
? 许多软件在开发时并未考虑将来的
修改，为软件的维护带来许多问题。
软件维护的策略
? 改正性维护
通常要生成 100％可靠的软件并不
一定合算，成本太高 。 但通过使用
新技术，可大大减少进行改正性维
护的需要 。
这些技术包括,数据库管理系统,
软件开发环境, 程序自动生成系统,
较高级 (第四代 )的语言 。 以及 新的
开发方法, 软件复用, 防错程序设
计 及 周期性维护审查 等 。
? 适应性维护
这一类维护不可避免，可以控制。
(1) 在配臵管理时，把硬件、操作
系统和其它相关环境因素的可能变
化考虑在内 。
(2) 把与硬件、操作系统，以及其
它外围设备有关的程序归到特定的
程序模块中。
(3) 使用内部程序列表、外部文件，
以及处理的例行程序包，可为维护
时修改程序提供方便。
? 完善性维护
利用前两类维护中列举的方法，也
可以减少这一类维护。特别是 数据
库管理系统, 程序生成器, 应用软
件包,可减少维护工作量。
此外，建立软件系统的原型，把它
在实际系统开发之前提供给用户。
用户通过研究原型，进一步完善他
们的功能要求，就可以减少以后完
善性维护的需要。
维护成本
? 有形的软件维护成本 是花费了多少
钱,无形的维护成本 有更大的影响。
? 一些 合理的修复或修改请求不能
及时安排,使得客户不满意；
? 变更的结果 引入新的故障,使得
软件整体质量下降；
? 把软件人员抽调到维护工作中，
干扰了软件开发工作。
? 软件维护的 代价 是 降低了生产率,
在做老程序的维护时非常明显。
? 例如,开发每一行源代码耗资 25美
元, 维护每一行源代码需要耗资
1000美元 。
? 维护工作量包括 生产性活动 （如分
析和评价、设计修改和实现）和
“轮转”活动 （如力图理解代码在
做什么、试图判明数据结构、接口
特性、性能界限等）。
维护工作量的模型
? M是维护中消耗的总工作量
? p是上面描述的生产性工作量
? K是一个经验常数
? c是因缺乏好的设计和文档而导致
复杂性的度量
? d是对软件熟悉程度的度量。
dcKepM ???
? 模型指明，如果使用了不好的软件
开发方法（未按软件工程要求做），
原来参加开发的人员或小组不能参
加维护，则工作量（及成本）将按
指数级增加。
软件维护活动
? 为了有效地进行软件维护，应事先
就开始做组织工作。
? 首先 建立维护的机构
? 申明 提出维护申请报告的过程 及
评价的过程
? 为每一个维护申请规定 标准的处
理步骤
? 建立 维护活动的登记制度 以及规
定 评价和评审的标准 。
维护机构
? 除了较大的软件开发公司外，通常
在软件维护工作方面，并不保持一
个正式的组织机构。
? 虽然不要求建立一个正式的维护机
构，但是在开发部门确立一个非正
式的维护机构则是非常必要的。
软件维护的机构
? 维护申请 提交给 维护管理员,他把
申请交给某个 系统监督员 去 评价 。
? 一旦做出评价，由 修改负责人 确定
如何进行修改 。
? 在修改程序的过程中，由 配臵管理
员 严格把关,控制修改的范围, 对
软件配臵进行审计 。
? 在维护之前，就把责任明确下来，
可以减少维护过程中的混乱。
软件维护申请报告
? 维护申请报告或称 软件问题报告,
由 申请维护的用户 填写 。
? 用户必须 完整地说明产生错误的情
况,包括 输入数据, 错误清单 以及
其它有关材料 。
? 如果申请的是适应性维护或完善性
维护，用户必须提出一份修改说明
书，列出所有希望的修改。
? 维护申请报告将由 维护管理员 和
系统监督员 来研究处理。
? 他们应相应地做出 软件修改报告,
指明：
? 所需修改变动的性质；
? 申请修改的优先级；
? 为满足某个维护申请报告，所
需的工作量；
? 预计修改后的状况,
? 软件修改报告应提交修改负责人，
经批准后才能开始进一步安排维
护工作。
软件维护
工作流程
? 尽管维护申请的类型不同，但都要
进行同样的技术工作。
? 修改软件需求说明
? 修改软件设计
? 设计评审
? 对源程序做必要的修改
? 单元测试
? 集成测试 ( 回归测试 )
? 确认测试
? 软件配臵评审等 。
在每次软件维护任务完成后进行情况
评审，对以下问题做一总结：
(1) 在目前情况下，设计、编码、测
试中的哪一方面可以改进?
(2) 哪些维护资源应该有但没有?
(3) 工作中主要的或次要的障碍是什
么?
(4) 从维护申请的类型来看是否应当
有预防性维护?
情况评审对将来的维护工作如何进行
会产生重要的影响。
维护档案记录
? 程序名称
? 源程序语句条数
? 机器代码指令条数
? 所用的程序设计语言
? 程序安装的日期
? 程序安装后的运行次数
? 与程序安装后运行次数有关的处
理故障次数
? 程序改变的层次及名称
? 修改程序增加的源程序语句条数
? 修改程序减少的源程序语句条数
? 每次修改所付出的“人时”数
? 修改程序的日期
? 软件维护人员的姓名
? 维护申请报告的名称、维护类型
? 维护开始时间和维护结束时间、
? 花费在维护上的累计“人时”数
? 维护工作的净收益等。
维护评价
? 评价维护活动比较困难,因为缺
乏可靠的数据。
? 如果维护的档案记录做得比较好，
可以得出一些维护“性能”方面
的度量值。
? 每次程序运行时的平均出错次数；
? 花费在每类维护上的总“人时”
数；
? 每个程序、每种语言、每种维
护类型的程序平均修改次数；
? 因为维护，增加或删除每个源
程序语句所花费的平均“人时”
数；
? 用于每种语言的平均“人时”
数；
? 维护申请报告的平均处理时间；
? 各类维护申请的百分比。
据此可对开发技术、语言选择、
维护工作计划、资源分配、以
及其它许多方面做出判定。
程序修改的步骤及修改的副作用
? 在软件维护时，必然会对源程序进
行修改。
? 通常对源程序的修改不能无计划地
仓促上阵，为了正确、有效地修改,
需要经历以下三个步骤。
? 分析和理解程序
? 修改程序
? 重新验证程序
分析和理解程序
? 经过分析,全面、准确、迅速地理
解程序是决定维护成败和质量好坏
的关键 。在这方面，软件的可理解
性和文档的质量非常重要。
? 理解程序的功能和目标；
? 掌握程序的结构信息，即从程序
中细分出若干结构成分。如程序
系统结构,控制结构、数据结构
和输入／输出结构等；
? 了解数据流信息，即涉及到的数
据来源何处，在哪里被使用；
? 了解控制流信息，即执行每条路
径的结果；
? 理解程序的操作 (使用 )要求；
? 为了容易地理解程序，要求自顶向
下地理解现有源程序的程序结构和
数据结构，为此可采用如下几种方
法：
1,分析程序结构图
(1) 搜集所有存储该程序的文件，
阅读这些文件，记下它们包含的过
程名,建立一个包括这些过程名和
文件名的清单 ；
(2) 分析各个过程的源代码,建立
一个直接调用矩阵 D或调用树 。若
过程 i 调用过程 j，则 D[i][j]＝ 1，
否则 D[i][j]＝ 0。
(3) 建立过程的间接调用矩阵 I，
即直接调用矩阵 D的传递闭包
I＝ D1∪ D2∪ D3∪ … ∪ Dn
其中,n是所包含的过程总数,
例如，过程 i 调用 j,j 调用 k，
则 D[i][j]＝ 1,D[j][k]＝ 1，
I[i][k]＝ 1。
(4) 分析各个过程的接口, 估计更
改的复杂性 。
2,数据跟踪
(1) 建立各层次的程序级上的接口
图,展示各模块或过程的调用方式
和接口参数；
(2) 利用数据流分析方法，对过程
内部的一些变量进行跟踪。 可获得
有关数据在过程间如何传递, 在过
程内如何处理 等信息。对于判断问
题原因特别有用。在跟踪的过程中
可在源程序中间插入自己的注释。
3,控制跟踪
控制流跟踪可采用符号执行或实际
动态跟踪的方法,了解数据如何从
一个输入源到达输出点的 。
4,充分阅读和使用源程序清单和文档,
分析现有文档的合理性。
5,充分使用由编译程序或汇编程序提
供的交叉引用表、符号表、以及其
它有用的信息。
6,如有可能，积极参加开发工作。
修改程序
? 对程序的修改，必须事先做出计划，
有预谋地、周密有效地实施修改。
1,设计程序的修改计划
程序的修改计划要考虑人员和资源
的安排。小的修改可以不需要详细
的计划，而对于需要耗时数月的修
改，就需要计划立案。
在编写有关问题解决的方案时，必
须充分描述修改作业的规格说明。
?规格说明信息：数据修改、处
理修改、作业控制语言修改、系统
之间接口的修改等；
?维护资源：新程序版本、测试
数据、所需软件、计算机时间等；
?人员；
?支持,纸面、计算机媒体等。
通常，可采用自顶向下的方法，在
理解程序的基础上，
(1) 研究程序的各个模块、模块的接
口、及数据库,从全局的观点，提
出修改计划。
(2) 依次地把 要修改的,以及 那些受
修改影响的模块和数据结构 分离出
来 。为此，要
?识别受修改影响的数据；
?识别使用这些数据的程序模块；
?对于上面程序模块，按是产生
数据、修改数据、还是删除数据
进行分类；
?识别对这些数据元素的外部控
制信息；
?识别编辑和检查这些数据元素
的地方；
?隔离要修改的部分；
(3) 详细地分析 要修改的,以及 那些
受变更影响的模块和数据结构 的内
部细节,设计修改计划,标明新逻
辑及要改动的现有逻辑。
(4) 向用户提供 回避措施 。用户的某
些业务因软件中发生问题而中断，
为不让系统长时间停止运行，需把
问题局部化,在可能的范围内继续
开展业务 。
可以采取的措施有：
① 查找问题原因,可能情况有：
?意外停机
?安装的期限到期
?系统运行中发现错误
② 如果弄清了问题的原因，可 通过
临时修改或改变运行控制以回避在
系统运行时产生的问题 。
2,修改代码，以适应变化
在修改时，要求：
(1) 正确、有效地编写修改代码；
(2) 要谨慎地修改程序，尽量保持
程序的风格及格式，要在程序清
单上注明改动的指令；
(3) 不要删除程序语句，除非完全
肯定它是无用的；
(4) 不要试图共用程序中已有的临
时变量或工作区，为了避免冲突
或混淆用途，应设臵自己的变量；
(5) 插入错误检测语句；
(6) 在修改过程中做好修改的详细
记录，消除变更中任何有害的副作
用（波动效应）；
3,修改程序的副作用
所谓副作用是指因修改软件而造成
的错误或其它不希望发生的情况。
副作用有三种,修改代码的副作用,
修改数据的副作用, 文档的副作用 。
? 在修改源代码时，都可能引入错误。
例如,删除或修改一个子程序, 删
除或修改一个标号, 删除或修改一
个标识符, 改变程序代码的时序关
系, 改变占用存储的大小, 改变逻
辑运算符, 修改文件的打开或关闭,
改进程序的执行效率,以及 把设计
上的改变翻译成代码的改变 时，都
容易引入错误。
(1) 修改代码的副作用
(2) 修改数据的副作用
? 在 修改数据结构 时，有可能造成 软
件设计与数据结构不匹配,因而导
致软件出错。
? 数据副作用就是修改软件信息结构
导致的结果。
? 容易导致设计与数据不相容的错误
可以有：
? 重新定义局部的或全局的常量
? 重新定义记录或文件的格式
? 增大或减小一个数组或高层数据
结构的大小
? 修改全局或公共数据
? 重新初始化控制标志或指针
? 重新排列输入／输出或子程序的
参数
? 数据副作用可以通过 交叉引用表 加
以控制。把数据元素、记录、文件
和其它结构联系起来。
(3) 文档的副作用
? 对 数据流, 软件结构, 模块逻辑 或
任何其它有关特性 进行修改时，必
须 对相关技术文档进行相应修改 。
否则会导致 文档与程序功能不匹配,
缺省条件改变, 新错误信息不正确
等错误。使得 软件文档不能反映软
件的当前状态 。
? 对于用户来说，软件事实上就是文
档。
? 如果对可执行软件的修改不反映在
文档里，就会产生文档的副作用。
? 对交互输入的顺序或格式进行修
改，如果没有正确地记入文档中，
就可能引起重大的问题。
? 过时的文档内容、索引和文本可
能造成冲突，引起用户失败和不
满。
? 因此,必须在软件交付之前对整个
软件配臵进行评审,以减少文档的
副作用。
? 为了控制因修改而引起的副作用，
要做到：
(1) 按模块把修改分组；
(2) 自顶向下地安排被修改模块的
顺序；
(3) 每次修改一个模块；
(4) 对于每个修改了的模块，在安
排修改下一个模块之前，要确定这
个修改的副作用。 可以使用交叉引
用表、存储映象表、执行流程跟踪
等。
重新验证程序
? 在将修改后的程序提交用户之前，
需要进行 充分的确认和测试,以
保证整个修改后程序的正确性。
? 静态确认
修改软件，伴随着引起新的错误
的危险 。为了能够做出正确的判
断，验证修改后的程序至少需要
两个人参加。要检查：
(1) 修改是否涉及到规格说明? 修
改结果是否符合规格说明? 有没有
歪曲规格说明?
(2) 程序的修改是否足以修正软件
中的问题? 源程序代码有无逻辑错
误? 修改时有无修补失误?
(3) 修改部分对其它部分有无不良
影响 (副作用 )?
对软件进行修改，常常会引发别的
问题，有必要检查修改的影响范围 。
? 计算机确认
在进行了以上确认的基础上，用计
算机对修改程序进行确认测试：
(1) 确认测试顺序,先对修改部分
进行测试，然后隔离修改部分，测
试程序的未修改部分，最后再把它
们集成起来进行测试。这种测试称
为回归测试。
(2) 准备标准的测试用例 。
(3) 充分利用软件工具帮助重新验
证过程 。
(4) 在重新确认过程中，需邀请用
户参加 。
? 维护后的验收 ──在交付新软件之
前，维护主管部门要检验：
(1) 全部文档是否完备，并已更新；
(2) 所有测试用例和测试结果已经
正确记载；
(3) 记录软件配臵所有副本的工作
已经完成；
(4) 维护工序和责任已经确定。
从维护角度来看所需测试种类
(1) 对 修改事务 的测试；
(2) 对 修改程序 的测试；
(3) 操作过程 的测试；
(4) 应用系统运用过程 的测试；
(5) 系统各部分之间接口 的测试；
(6) 作业控制语言 的测试；
(7) 与系统软件接口 的测试；
(8) 软件系统之间接口 的测试；
(9) 安全性 测试；
(10) 后备／恢复过程 的测试。
软件可维护性
? 许多软件的维护十分困难，原因在
于这 些软件的文档不全, 质量差,
开发过程不注意采用好的方法, 忽
视程序设计风格 等。
? 许多维护要求并不是因为程序中出
错而提出的，而是为 适应环境变化
或 需求变化 而提出的。
? 为了使得软件能够易于维护，必须
考虑使软件具有 可维护性 。
软件可维护性的定义
? 软件可维护性 是指 纠正软件系统出
现的错误和缺陷，以及为满足新的
要求进行修改、扩充或压缩的容易
程度 。
? 可维护性, 可使用性, 可靠性 是衡
量软件质量的主要质量特性，也是
用户十分关心的几个方面。
? 软件的 可维护性 是 软件开发阶段各
个时期的关键目标 。
? 目前广泛使用的是用如下的七个特
性来衡量程序的可维护性。
可理解性 可使用性
可测试性 可移植性
可修改性 效率
可靠性
? 而且对于不同类型的维护，这七种
特性的侧重点也不相同 。
在各类维护中的侧重点
改改 正正 性性 维维 护护 适适 应应 性性 维维 护护 完完 善善 性性 维维 护护
可可 理理 解解 性性 ??
可可 测测 试试 性性 ??
可可 修修 改改 性性 ?? ??
可可 靠靠 性性 ??
可可 移移 植植 性性 ??
可可 使使 用用 性性 ?? ??
效效 率率 ??
? 这些质量特性通常体现在软件产品
的许多方面 ;
? 为使每一个质量特性都达到预定的
要求，需要在软件开发的各个阶段
采取相应的措施加以保证。
? 这些质量要求要渗透到而各开发阶
段的各个步骤当中 。因此，软件的
可维护性是产品投入运行以前各阶
段面向上述各质量特性要求进行开
发的最终结果。
可维护性的度量
? 人们一直期望 对软件的可维护性做
出定量度量,但要做到这一点并不
容易。
? 常用的度量一个可维护的程序的七
种特性的方法。就是
? 质量检查表
? 质量测试
? 质量标准
? 质量检查表 是用于测试程序中某些
质量特性是否存在的一个问题清单。
? 评价者针对检查表上的每一个问题，
依据自己的定性判断，回答,Yes”
或者,No”。
? 质量测试 与 质量标准 则用于定量分
析和评价程序的质量。
? 由于许多质量特性是相互抵触的，
要 考虑几种不同的度量标准,相应
地去度量不同的质量特性。
1,可理解性
? 可理解性表明人们通过阅读源代码
和相关文档，了解程序功能及其如
何运行的容易程度。
? 一个可理解的程序应具备以下一些
特性,模块化, 风格一致性, 不使
用令人捉摸不定或含糊不清的代码,
使用有意义的数据名和过程名, 结
构化, 完整性 等。
2,可靠性
? 可靠性表明一个程序按照用户的要
求和设计目标，在给定的一段时间
内正确执行的概率。
? 关于可靠性，度量的标准主要有：
? 平均失效间隔时间 MTTF
? 平均修复时间 MTTR
? 有效性 A = MTBD/(MTBD+MDT)
度量可靠性的方法
? 根据程序错误统计数字，进行可靠
性预测 。常用方法是利用一些 可靠性
模型, 根据程序测试时发现并排除的
错误数预测平均失效间隔时间 MTTF。
? 根据程序复杂性，预测软件可靠性 。
用程序复杂性预测可靠性,前提条件
是可靠性与复杂性有关 。因此可用复
杂性预测出错率。程序复杂性度量标
准可用于 预测哪些模块最可能发生错
误,以及 可能出现的错误类型 。
3,可测试性
? 可测试性表明论证程序正确性的容
易程度 。程序越简单，证明其正确
性就越容易。而且设计合用的测试
用例，取决于对程序的全面理解。
? 一个可测试的程序应当是 可理解的,
可靠的, 简单的 。
? 用于可测试性度量的检查项目如下：
? 程序是否模块化? 结构是否良好?
? 程序是否可理解? 程序是否可靠?
? 程序是否能显示任意中间结果?
? 程序是否能以清楚的方式描述它的
输出?
? 程序是否能及时地按照要求显示所
有的输入?
? 程序是否有跟踪及显示逻辑控制流
程的能力?
? 程序是否能从检查点再启动?
? 程序是否能显示带说明的错误信息?
4,可修改性
? 可修改性表明程序容易修改的程度 。
? 一个可修改的程序应当是 可理解的,
通用的, 灵活的, 简单的 。
? 通用性是指程序适用于各种功能变
化而无需修改。
? 灵活性是指能够容易地对程序进行
修改。
? 测试可修改性的一种定量方法是
修改练习 。其基本思想是 通过做
几个简单的修改, 来评价修改的
难度 。
? 设 C是程序中各个模块的平均复杂
性,n是必须修改的模块数,A 是
要修改的模块的平均复杂性。 则
修改的难度 D由下式计算：
D = A / C
5,可移植性
? 可移植性表明程序转移到一个新的
计算环境的可能性的大小 。或者它
表明程序可以容易地、有效地在各
种各样的计算环境中运行的容易程
度。
? 一个可移植的程序应具有 结构良好,
灵活, 不依赖于某一具体计算机或
操作系统的性能 。
? 用于可移植性度量的检查项目如下：
? 是否是用高级的独立于机器的语言
来编写程序?
? 是否使用广泛使用的标准化的程序
设计语言来编写程序? 是否仅使用
了这种语言的标准版本和特性?
? 程序中是否使用了标准的普遍使用
的库功能和子程序?
? 程序中是否极少使用或根本不使用
操作系统的功能?
?程序在执行之前是否初始化内存?
? 程序在执行之前是否测定当前的
输入／输出设备?
? 程序是否把与机器相关的语句分
离了出来，集中放在了一些单独的
程序模块中，并有说明文件?
? 程序是否结构化? 并允许在小一
些的计算机上分段 (覆盖 )运行?
? 程序中是否避免了依赖于字母数
字或特殊字符的内部位表示?
6,效率
? 效率表明一个程序能执行预定功能
而又不浪费机器资源的程度 。
? 这些机器资源包括 内存容量, 外存
容量, 通道容量 和 执行时间 。
? 用于效率度量的检查项目如下,
? 程序是否模块化? 结构是否良好?
? 是否消除了无用的标号与表达式，
以充分发挥编译器优化作用?
? 程序的编译器是否有优化功能?
? 是否把特殊子程序和错误处理
子程序都归入了单独的模块中?
? 是否以快速的数学运算代替了
较慢的数学运算?
? 是否尽可能地使用了整数运算，
而不是实数运算?
? 是否在表达式中避免了混合数
据类型的使用，消除了不必要的
类型转换?
? 程序是否避免了非标准的函数或
子程序的调用?
? 在几条分支结构中，是否最有可
能为“真”的分支首先得到测试?
? 在复杂的逻辑条件中，是否最有
可能为“真“的表达式首先得到
测试?
7,可使用性
? 从用户观点出发,可使用性定义为
程序方便、实用、及易于使用的程
度 。一个可使用的程序应是 易于使
用的, 能允许用户出错和改变,并
尽可能不使用户陷入混乱状态的 程
序。
? 用于可使用性度量的检查项目如下：
? 程序是否具有自描述性?
? 程序是否能始终如一地按照用
户的要求运行?
? 程序是否让用户对数据处理有
一个满意的和适当的控制?
? 程序是否容易学会使用?
? 程序是否使用数据管理系统来
自动地处理事务性工作和管理格
式化、地址分配及存储器组织。
? 程序是否具有容错性?
? 程序是否灵活?
其它间接定量度量可维护性的方法
? 问题识别的时间；
? 因管理活动拖延的时间；
? 收集维护工具的时间；
? 分析、诊断问题的时间；
? 修改规格说明的时间；
? 具体的改错或修改的时间；
? 局部测试的时间；
? 集成或回归测试的时间；
? 维护的评审时间；
? 这些数据反映了维护全过程中 检
错－纠错－验证 的周期，即 从检
测出软件存在的问题开始至修正
它们并经回归测试验证这段时间 。
? 可以粗略地认为,这个周期越短，
维护越容易 。
提高可维护性的方法
? 建立明确的软件质量目标和
优先级
? 使用提高软件质量的技术和
工具
? 进行明确的质量保证审查
? 选择可维护的程序设计语言
? 改进程序的文档
建立明确的软件质量目标和优先级
? 一个可维护的程序应是 可理解的,
可靠的, 可测试的, 可修改的, 可
移植的, 效率高的, 可使用的 。
? 要实现这所有的目标，需要付出很
大的代价，而且也不一定行得通。
? 某些质量特性是相互促进的,例如
可理解性和可测试性、可理解性和
可修改性。
? 另一些质量特性是相互抵触的,如
效率和可移植性、效率和可修改性
等。
? 每一种 质量特性 的 相对重要性 应随
程序的用途及计算环境的不同而不
同 。例如，对编译程序来说，可能
强调效率；但对管理信息系统来说，
则可能强调可使用性和可修改性。
? 应当对程序的质量特性，在 提出目
标 的同时还必须 规定它们的优先级 。
使用提高软件质量的技术和工具
? 模块化
? 如果需要改变某个模块的功能，
则只要改变这个模块，对其它模块
影响很小；
? 如果需要增加程序的某些功能，
则仅需增加完成这些功能的新的模
块或模块层；
? 程序的测试与重复测试比较容易；
? 程序错误易于定位和纠正；
? 结构化程序设计
? 程序被划分成分层的模块结构；
? 模块调用控制必须从模块的入口
点进入，从其出口点退出。
? 模块的控制结构仅限于顺序、选
择、重复三种，且没有 GOTO语
句。
? 每个程序变量只用于唯一的程序
目的，而且变量的作用范围应是
明确的、有限制的。
? 使用结构化程序设计技术，提高现
有系统的可维护性
? 采用备用件的方法 ──用一个新的
结构良好的模块替换掉整个要修改
的模块。
? 采用自动重建结构和重新格式化
的工具 (结构更新技术 )──把非结构
化代码转换成良好结构代码 。
? 改进现有程序的不完善的文档 ─ ─
建立或补充系统说明书、设计文档、
模块说明书、以及在源程序中插入
必要的注释。
进行明确的质量保证审查
? 质量保证审查 对于 获得和维持软件
的质量,是一个很有用的技术。
? 审查 可以用来 检测在开发和维护阶
段内发生的质量变化 。
? 一旦检测出问题来，就可以采取措
施来纠正，以控制不断增长的软件
维护成本，延长软件系统的有效生
命期。
? 保证软件质量的最佳方法是 在软件
开发的最初阶段把质量要求考虑进
去,并 在开发过程每一阶段的终点,
设臵检查点进行检查 。
? 检查的目的是要证实，已开发的软
件 是否符合标准, 是否满足规定的
质量需求 。在不同的检查点，检查
的重点不完全相同。
1,在检查点进行复审
软件开发期间各个检查点的检查重点
? 在设计阶段，检查重点是 可理解性,
可修改性, 可测试性 。
? 可理解性 检查的重点是 程序的复杂
性 。对每个模块可用 McCabe环路
来计算模块的复杂性，若大于 10，
则需重新设计。
? 可以使用各种 质量特性检查表,或
用 度量标准 来检查可维护性。
? 审查小组可以采用人工测试一类的
方式，进行审查。
2,验收检查
? 验收检查 是一个 特殊的检查点 的检
查，是交付使用前的 最后一次检查,
? 验收检查 实际上是 验收测试 的一部
分，只不过它是从维护的角度提出
验收的条件和标准。
? 验收检查必须遵循的最小验收标准。
(1) 需求和规范标准
① 需求应当以可测试的术语进行
书写，排列优先次序和定义；
② 区分必须的、任选的、将来的
需求；
③ 包括对系统运行时的计算机设
备的需求；对维护、测试、操作、
以及维护人员的需求；对测试工具
等的需求。
(2) 设计标准
① 程序应设计成分层的模块结
构。每个模块应完成唯一的功能，
并达到高内聚、低耦合；
② 通过一些知道预期变化的实
例，说明设计的可扩充性、可缩减
性和可适应性。
(3) 源代码标准
① 尽可能使用最高级的程序设
计语言，且只使用语言的标准版本；
② 所有的代码都必须具有良好
的结构；
③ 所有的代码都必须文档化，
在注释中说明它的输入、输出、以
及便于测试／再测试的一些特点与
风格。
(4) 文档标准
文档中应说明
? 程序的输入／输出
? 使用的方法／算法
? 错误恢复方法
? 所有参数的范围
? 缺省条件等。
3,周期性地维护审查
? 检查点复查 和 验收检查,可用来 保
证新软件系统的可维护性 。
? 对已有的软件系统，则应当 进行周
期性的维护检查 。
? 软件在运行期间进行修改，会导致
软件质量有变坏的危险，破坏程序
概念的完整性。
? 必须 定期检查,对软件做周期性的
维护审查,以跟踪软件质量的变化 。
? 周期性维护审查 实际上是开发阶段
检查点复查的继续，并且 采用的检
查方法, 检查内容都是相同的 。
? 维护审查的结果 可以同 以前的维护
审查的结果, 以前的验收检查的结
果, 检查点检查的结果 相比较，任
何一种改变都表明在软件质量上或
其它类型的问题上可能起了变化。
? 对于改变的原因应当进行分析 。
4,对软件包进行检查
? 软件包 是一种 标准化 的，可 为不同
单位, 不同用户使用 的软件。
? 一般 源代码和程序文档 不会提供给
用户。
? 对软件包的维护采取以下方法。
? 使用单位的维护人员首先要仔细
分析、研究卖主提供的用户手册、
操作手册、培训教程等，以及卖
方提供的验收测试报告等。
? 在此基础上，深入 了解本单位的希
望和要求, 编制软件包的检验程序 。
检查软件包程序所执行的功能是否
与用户的要求和条件相一致。
? 为了建立这个程序，维护人员可以
利用卖方提供的验收测试实例,还
可以自 己重新设计新的测试实例 。
? 根据测试结果，检查和验证软件包
的参数或控制结构，以完成软件包
的维护。
选择可维护的程序设计语言
? 程序设计语言的选择，对程序的可
维护性影响很大。
机器语言 汇编语言 高级语言 查询语言
(FORTRAN,报表生成语言
COBOL等 ) 图象语言
应用生成语言
改进程序的文档
? 程序文档是对程序 总目标, 程序各
组成部分之间的关系, 程序设计策
略, 程序实现过程的历史数据 等的
说明和补充。
? 即使是一个十分简单的程序，要想
有效地、高效率地维护它，也需要
编制文档来解释其目的及任务。
? 对于程序维护人员来说，要想 按程
序编制人员的意图重新改造程序,
并对今后变化的可能性进行估计，
缺了文档是不行的。
? 因此，为了维护程序，人们必须阅
读和理解文档。
? 另外，在软件维护阶段，利用 历史
文档,可以大大简化维护工作。通
过了解原设计思想，可以判断出错
之处，指导维护人员选择适当的方
法修改代码而不危及系统的完整性。
? 历史文档有三种：
? 系统开发日志
? 错误记载
? 系统维护日志
