预防性维护

软件并控制维护的成本。
8
• 系统大小：系统越大，理解掌握起来越困难。系
统越大，所执行功能越复杂。因而需要更多的维 护工作量。 • 程序设计语言：使用强功能的程序设计语言可以 控制程序的规模。语言的功能越强，生成程序的 模块化和结构化程度越高，所需的指令数就越少， 程序的可读性越好。
9
• 系统年龄： – 老系统随着不断的修改，结构越来越乱；
性。
31
2. 数据跟踪 (1) 建立各层次的程序级上的接口图，展示各 模块或过程的调用方式和接口参数； (2) 利用数据流分析方法，对过程内部的一些
变量进行跟踪。可获得有关数据在过程间如
何传递，在过程内如何处理等信息。对于判
断问题原因特别有用。在跟踪的过程中可在
源程序中间插入自己的注释。
32
3. 控制跟踪
改正性维护
适应性维护
18%～ 25%
17%～ 21%
其它维护 4 %
扩充与完善性维护
50% ～ 60%
7
7.2
软件维护的特点 -- 影响维护工作量的因素
• 在软件的维护过程中，需要花费大量的工作量，
从而直接影响了软件维护的成本。
• 应当考虑有哪些因素影响软件维护的工作量，
相应应该采取什么维护策略，才能有效地维护
维护工作 量的模型
M 是维护中消耗的总工作量 P 是生产性工作量 K 是一个经验常数 c 是因缺乏好的设计和文档而导致复杂性的度量 d 是维护人员对软件熟悉程度的度量
• 模型指明，如果使用了不好的软件开发方法（未
按软件工程要求做），原来参加开发的人员或小 组不能参加维护，则工作量（及成本）将按指数 级增加。
27
分析和理解程序

经过分析，全面、准确、迅速地理解程序是
决定维护成败和质量好坏的关键。在这方面，
软件的可理解性和文档的质量非常重要。


理解程序的功能和目标；
掌握程序的结构信息，即从程序中细分出 若干结构成分。如程序系统结构、 控制结 构、数据结构和输入／输出结构等；
28

了解数据流信息，即涉及到的数据来源何
• 他们应相应地做出软件修改报告，指明：
– 所需修改变动的性质；
– 申请修改的优先级； – 为满足某个维护申请报告，所需的工作量 – 预计修改后的状况. • 软件修改报告应提交给变化授权人（修改负责人），经批准 后才能开始进一步安排维护工作。
19
3. 维护的事件流
20
• 尽管维护申请的类型不同，但都要进行同样的技 术工作。 – 修改软件需求说明 – 修改软件设计
用户报表应用软件的维护工作量。
10
• 先进的软件开发技术：在软件开发时，若使用能 使软件结构比较稳定的分析与设计技术，及程序 设计技术，如面向对象技术、复用技术等，可减 少大量的工作量。 • 其它：
– 应用的类型
– 数学模型 – 任务的难度
– 开关与标记、IF嵌套深度、索引或下标数等
对维护工作量都有影响。 • 许多软件在开发时并未考虑将来的修改，为软件 的维护带来许多问题。 11
– 维护人员经常更换，程序又变得越来越难于理解
– 许多老系统在当初并未按照软件工程的要求进行
开发，因而没有文档，或文档太少。
– 在长期的维护过程中文档在许多地方与程序实现 变得不一致，在维护时就会遇到很大困难。 • 数据库技术的应用：使用数据库，可以简单而有效 地管理和存储用户程序中的数据，还可以减少生成
语言选择、维护工作量规划、资源分配及其他许多方面的 决定，而且可以利用这样的数据去分析评价维护任务。
26
6、程序修改的步骤及修改的副作用 • 在软件维护时，必然会对源程序 进行修改。 • 通常对源程序的修改不能无计划 地仓促上阵，为了正确、有效地 修改,需要经历以下三个步骤。 • 分析和理解程序 • 修改程序 • 重新验证程序
39
2. 修改代码，以适应变化 在修改时，要求： (1) 正确、有效地编写修改代码；
• 这些隐藏下来的错误在某些特定的使用 环境下就会暴露出来。
• 为了识别和纠正软件错误、改正软件性 能上的缺陷、排除实施中的误使用，所 进行的诊断和改正错误的过程就叫做改
正性维护。
3
适应性维护 ---
Adaptive Maintenance
• 在使用过程中， – 外部环境（新的硬、软件配臵） – 数据环境（数据库、数据格式、 数据输入/输出方式、数据存储介 质） 可能发生变化。 • 为使软件适应这种变化，而去修改
13
7.2.3
维护中的典型问题
(1) 难以跟踪软件版本的进化过程,软件
的变化未在文档中反映出来.
(2) 难以跟踪软件的创建过程. (3) 难以读懂他人程序.
(4) 无文档或不全.
(5) 软件人员流动性大.Fra Baidu bibliotek
(6) 设计时未考虑修改需要,修改困难.
(7) 维护工作无吸引力,缺乏成就感.
采用软件工程方法至少可部分地解决 与维护有关的每一个问题。
处，在哪里被使用；



了解控制流信息，即执行每条路径的结果；
理解程序的操作(使用)要求；
为了容易地理解程序，要求自顶向下地理解
现有源程序的程序结构和数据结构，为此可
采用如下几种方法：
29
1. 分析程序结构图 (1) 搜集所有存储该程序的文件，阅读这些文 件，记下它们包含的过程名，建立一个包括 这些过程名和文件名的清单； (2) 分析各个过程的源代码，建立一个直接调 用矩阵D或调用树。若过程 i 调用过程 j，则
D[i][j]＝1，否则D[i][j]＝0。
30
(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) 分析各个过程的接口，估计更改的复杂
36
对于上面程序模块，按是产生数据、修 改数据、还是删除数据进行分类； 识别对这些数据元素的外部控制信息； 识别编辑和检查这些数据元素的地方； 隔离要修改的部分；
37
(3) 详细地分析要修改的、以及那些受变更影响 的模块和数据结构的内部细节，设计修改计
划，标明新逻辑及要改动的现有逻辑。
14
7.3
软件维护过程
• 维护过程本质上是修改和压缩了的软件定义和开 发过程，而且事实上远在提出一项维护要求之前， 与软件维护有关的工作已经开始了。 • 为了有效地进行软件维护，应事先就开始做组织 工作。 – 首先建立维护的机构 – 申明提出维护申请报告的过程及评价的过程 – 为每一个维护申请规定标准的处理步骤 – 建立维护活动的记录保管，并规定复审的标准
1. 设计程序的修改计划 程序的修改计划要考虑人员和资源的安排。 小的修改可以不需要详细的计划，而对于需 要耗时数月的修改，就需要计划立案。
34
在编写有关问题解决的方案时，必须充分描 述修改作业的规格说明。
规格说明信息：数据修改、处理修改、作
业控制语言修改、系统之间接口的修改等；
维护资源：新程序版本、测试数据、所需
软件的过程就叫做适应性维护。
4
扩充与完善性维护 --- Perfective Maintenance
• 在软件的使用过程中，用户往往会对软 件提出新的功能与性能要求。 • 为了满足这些要求，需要修改或再开发 软件，以扩充软件功能、增强软件性能、 改进加工效率、提高软件的可维护性。 • 这种情况下进行的维护活动叫做扩充与
2. 维护报告
• 应该用标准化的格式表达所有软件维护申请（要
求）。
• 维护申请报告或称软件问题报告，由申请维护的
用户填写。
• 用户必须完整地说明产生错误的情况，包括输入
数据、错误清单以及其它有关材料。
• 如果申请的是适应性维护或完善性维护，用户必
须提出一份修改说明书，列出所有希望的修改。
18
• 维护申请报告将由维护管理员和系统管理员来研究处理。
情况评审对将来的维护工作如何进行会产生重要的影
响。
22
4、维护档案记录
①程序标识；
②源语句数；
③机器指令条数；
④使用的程序设计语言；
⑤程序安装的日期； ⑥自从安装以来程序运行的次数； ⑦自从安装以来程序失效的次数； ⑧程序变动的层次和标识； ⑨因程序变动而增加的源语句数；
23
⑽ 因程序变动而删除的源语句数；
15
1、维护机构 • 除了较大的软件开发公司外， 通常在软件维护工作方面，并 不保持一个正式的组织机构。 • 虽然不要求建立一个正式的维 护机构，但是在开发部门确立 一个非正式的维护机构则是非 常必要的。
16
• 每个维护要求都通过维护管理员转交给相应的系 统管理员去评价（系统管理员是被指定去熟悉一 小部分产品程序的技术人员）。 • 系统管理员对维护任务做出评价之后，由变化授 权人决定应该进行的活动。 17
控制流跟踪可采用符号执行或实际动态跟踪的
方法，了解数据如何从一个输入源到达输出点
的。
4. 充分阅读和使用源程序清单和文档，分析现有
文档的合理性。
5. 充分使用由编译程序或汇编程序提供的交叉引
用表、符号表、以及其它有用的信息。
6. 如有可能，积极参加开发工作。
33
修改程序

对程序的修改，必须事先做出计划，有预谋 地、周密有效地实施修改。
– 设计评审
– 对源程序做必要的修改 – 单元测试 – 集成测试( 回归测试) – 确认测试
– 软件配臵评审等。
21
在每次软件维护任务完成后进行情况评审，对以下问题
做一总结： (1) 在目前情况下，设计、编码、测试中的哪一方面可 以改进? (2) 哪些维护资源应该有但没有? (3) 工作中主要的或次要的障碍是什么? (4) 从维护申请的类型来看是否应当有预防性维护?
完善性维护。
5
预防性维护 --- Preventive Maintenance • 预防性维护是为了提高软件的可维 护性、可靠性等，为以后进一步改 进软件打下良好基础。
• 预防性维护定义为：采用先进的软 件工程方法对需要维护的软件或软 件中的某一部分（重新）进行设计、 编制和测试。
6

各种维护所占比例:
方面的度量值。
(1) 每次程序运行平均失效的次数； (2) 用于每一类维护活动的总人时数； (3) 平均每个程序、每种语言、每种维护类型所做的程序变动 数；
25
(4) 维护过程中增加或删除一个源语句平均花费的人时数； (5) 维护每种语言平均花费的人时数； (6) 一张维护要求表的平均周转时间； (7) 不同维护类型所占的百分比。 • 根据对维护工作定量度量的结果，可以做出关于开发技术、
软件、计算机时间等；
人员；
支持：纸面、计算机媒体等。
35
通常，可采用自顶向下的方法，在理解程序
的基础上，
(1) 研究程序的各个模块、模块的接口、及数
据库，从全局的观点，提出修改计划。
(2) 依次地把要修改的、以及那些受修改影响
的模块和数据结构分离出来。为此，要
识别受修改影响的数据；
识别使用这些数据的程序模块；
⑾ 每个改动耗费的人时数；
⑿ 程序改动的日期； ⒀ 软件工程师的名字； ⒁ 维护要求表的标识； ⒂ 维护类型；
⒃ 维护开始和完成的日期；
⒄ 累计用于维护的人时数； ⒅ 与完成的维护相联系的纯效益。
24
5、维护评价
• 评价维护活动比较困难，因为缺乏可靠的数据。 • 如果维护的档案记录做得比较好，可以得出一些维护“性能”
(4) 向用户提供回避措施。用户的某些业务因软
件中发生问题而中断，为不让系统长时间停
止运行，需把问题局部化，在可能的范围内
继续开展业务。
可以采取的措施有：
38
① 查找问题原因，可能情况有： 意外停机 安装的期限到期 系统运行中发现错误 ② 如果弄清了问题的原因，可通过临时修改或 改变运行控制以回避在系统运行时产生的问 题。
第七章
软 件 维 护
1
第7章 软件维护
7.1 软件维护的定义
软件维护 ---- 就是在软件已经交付使用之后，
为了改正错误或满足新的需要而修改软件的过
程。
维护的类型有四种：
改正性维护 适应性维护 扩充与完善性维护 预防性维护
2
改正性维护 --- Corrective Maintenance
• 在软件交付使用后，因开发时测试的不 彻底、不完全，必然会有部分隐藏的错 误遗留到运行阶段。
维护成本
• 有形的软件维护成本是花费了多少 钱，无形的维护成本有更大的影响。 – 一些合理的修复或修改请求不 能及时安排，使得客户不满意； – 变更的结果引入新的故障，使 得软件整体质量下降； – 把软件人员抽调到维护工作中， 干扰了软件开发工作。
12
M p Ke
• • • • •
c d