2009-7-261
2
第 5章 软件维护
软件维护的概念
软件维护的活动
软件的可维护性
软件再工程
3
6.1 软件维护的概念当软件系统在实际环境被用户使用时，软件开发宣告结束。但软件总是要变化的，在软件交付使用后修改软件的过程称为软件维护。
软件维护一般不包括重大的体系结构的改变，变更的实现方法一般是修改已有的系统构件以及在必要的地方添加新构件到系统中。
1、软件维护的分类
改正性维护：修改软件缺陷。
适应性维护：适应变更的操作环境（硬件、操作系统平台、其他支持软件）。
增强性维护：系统需求改变（机构因素、业务改变）。
4
Lientz和 Swanson(1980)对维护的工作量做过调查，
如图所示。 Nosek和 Palvia(1990)在十年后给出的数据与此相似。
适应性维护和增强性维护占了绝大部分工作量。维护是系统开发过程的自然延续，同样也涉及到需求描述、设计、实现和测试活动。
5
2、维护的成本维护成本和开发成本的比例在不同的应用域中是不同的。 Guimaraes(1983)的研究表明，对于业务应用系统，维护成本和系统开发成本大体相等。对于嵌入式实时系统，维护费用是开发成本的四倍以上。
带来高维护费用的关键因素：
人员的不稳定
合同责任
维护人员技术水平
系统结构衰退遗留系统的结构受到频繁变更的破坏；没有使用现代的软件工程技术开发；文档不全、不一致；没有采用配置管理，
系统变更时在寻找系统构件的合适版本上浪费时间。
6
Belady和 Lehman提出了一个计算维护工作量的模型：
M＝ p＋ K× e(c－ d)
其中 M：软件维护所有的工作量；
p：生产性工作量（分析、设计、编码及测试）；
K：经验常数；
c：复杂程度；
d：维护人员对软件的熟悉程度。
该模型描述了影响维护的诸多因素中重要的关系。如果一个系统开发没有遵循软件工程原则，软件结构不好，
c的值就会很高，再加上维护人员对软件的不熟悉,d的值很低。结果是，维护的成本呈指数级的增长。
7
如何降低软件维护的费用？
（ 1） 从开发阶段的一开始就按质量标准构建系统,给予,可维护性,属性以足够的重视,这样可以使系统的整个生命周期成本减少 。 下图说明了这个问题 。 系统 1在开发成本中多投入 $25000,用于提高系统的可维护性,结果在整个生命周期中节省了 $100 000的维护成本 。
8
（ 2）采用演化式的系统开发模型（如增量、螺旋），
建立能结合新需求而演化和变更的系统。
（ 3）实施软件再工程，改善系统结构，提高可维护性。
9
6.2 软件维护活动
Pfleeger和 Bohner(1990)提出了软件维护的一种模型，
其中包含了度量的反馈，见下图：
10
该图说明了当要求进行一项变动时要执行的活动，底部带标注的箭头代表提供的度量信息，管理人员利用这些信息决定什么时候和怎样进行变动。
维护活动：
（ 1）变更分析各种变更带来的的负面影响：
产生不正确或不完整的补丁软件、结构很差的设计与编码、构件不标准等等。
这些负面影响使软件复杂性增加，更不易理解。因此对变更的成本、影响要进行分析。
（ 2）理解变更，规划新版本根据变更的类型（缺陷修正、适应性调整或增加新功能），决定哪些变更在下一个版本中完成。
11
（ 3）实现变更分析系统变更的需求（如有必要，可对提出的变更建立原型），对系统构件重新设计，编码、测试。软件开发中重要的配置管理思想在这里同样适用。
对于紧急变更，保证更快速度完成比保证变更过程规范化更重要。
（ 4）后果分析维护活动中改动的是需求、设计与代码构件、测试用例以及文档等工作产品。一个工作产品的质量可能影响到其他工作产品,Pfleeger（ 1990）提出必须建立并跟踪工作产品之间的关系，帮助我们评估一个构件的变更对所有其他构件的影响。下图展示了工作产品之间的关系及可追踪性：
12
R1
R2
R3
Ri
D1
D2
D3
Dj
.
.
.
.
.
.
水平追踪连接
C1
C2
C3
Ck
.
.
.
T1
T2
T3
Tn
.
.
.
垂直追踪连接需求 设计 代码 测试工作产品的追踪图
13
其中：每个矩形框内的结点表示为该阶段产生的工作产品或构件。构件及之间的实线箭头构成了 度量产品的垂直跟踪图 。某一阶段内（矩形框内），在产品变动前后分别对以下度量指标求值：
结点总数、指向一个结点的边数（该结点的入度）、
一个结点发出的边数（出度）、环路数。
Pfleeger提出计算最小路径集，如果变动后覆盖的路径增加，或者结点的入度、出度增加，则系统会更复杂、
更难于维护。利用此信息，维护组可能决定用另一种方式实现或者取消该变动。
虚线箭头连接的图构成了系统的 水平跟踪图,代表了对变动的一个 过程的度量 。每一对工作产品：需求产品与设计产品，设计产品与代码产品，代码产品与测试用例，
在两者之间形成关系子图，度量规模和复杂性关系，从而得出负面影响。还可浏览整个水平跟踪图，了解变动后总的可追踪性变得更复杂还是简单了。
14
6.3 软件可维护性软件的可维护性、可靠性和可用性是衡量软件质量的几个主要特性，是用户最关心的几个问题。
软件可维护性可定性地定义为：维护人员理解、改正、
改动和改进这个软件的难易程度。
1、用于衡量可维护性的软件特性,
可用下面 7个质量特性来衡量：
可理解性、可测试性、可修改性、可靠性、可移植性、
可使用性 和 效率 。
对于不同类型的维护，这 7种特性的侧重点也不相同。
要将这些质量要求贯彻到各开发阶段的各步骤中。软件的可维护性是产品投入运行以前各阶段针对上述各质量特性要求进行开发的最终结果。
15
开发阶段 可维护性因素需求分析? 明确维护的范围和责任。
检查每条需求，分析维护时可能需要的支持。
明确哪些资源可能会变化以及带来的影响。
了解系统可能的扩展与变更。
设计阶段? 设计系统扩展、压缩或变更的方法（如将变动部分与稳定部分分离）。
做一些变更或适应不同软硬件环境的实验。
遵循高内聚、低耦合原则。
设计界面不受系统内部变更的影响。
每一个模块只完成一个功能。
16
编码阶段? 检查源程序与文档的一致性。
检查源程序的可理解性。
源程序是否符合编码规范。
测试阶段? 维护人员与测试人员一起按照需求文档和设计文档测试软件的有效性、可用性。
维护人员将收集的出错信息分类统计，为今后的维护奠定基础。
17
2、可维护性的度量
（ 1）使用质量检查表度量一个可维护性的软件的 7种特性。质量检查表是用于测试程序中某些质量特性是否存在的一个问题清单，检查者对表上的每一个问题，回答“是”
或“否”。
（ 2）间接地度量可维护性（面向时间的度量）：
察觉到问题所耗的时间；
分析问题所用的时间；
形成修改说明所需时间；
修改所用时间；
局部测试所用时间；
整体测试所用时间；
维护复审所用时间；
完全恢复所用时间。
有关设计结构和软件复杂性的度量也可间接说明软件的可维护性。
18
3、如何提高软件的可维护性
（ 1）建立明确的软件质量目标；
有一些特性是相互促进的，有一些是相互矛盾的，根据用途不同或计算机环境不同，确定最重要的特性。
（ 2）使用先进的开发技术和工具；
传统方法开发的软件结构紧密相关于所要完成的功能，
结构不稳定。
（ 3）建立明确的质量保证措施；
在各里程碑处检查与可维护性相关的软件特性。
（见下图）
19
分析 设计 编码 测试 验收 配置复审可靠性可移植性可用性可理解性可修改性可测试性可理解性可修改性可移植性效率可靠性效率 完整性一致性可理解性各里程碑处对与可维护性相关的软件特性的检查：
（ 4）选择易理解、易编程的语言，如 4GL ；
（ 5）建立完整、一致和正确的文档。
20
6.4 软件再工程在许多有大量软件的企业中，维护这些软件是一个挑战！
如一个保险公司使用多种实现语言在不同平台上支持许多不同的应用程序，例如有一个应用程序处理某种类型的保险单、保单持有人信息、保险统计与记帐信息。这样的保单可能要维持数十年。有时不到最后一个保单持有人死亡并且每一项索赔都得到支付，是不可能报废软件的。
这些软件有的已老化，虽然经常出错，但对业务处理提供了有力的支持。企业还要依赖这些系统，却很难决定怎样使这些系统更易于维护。其选择可能是扩充或者用新技术替换；每种选择都希望在成本尽可能低的情况下保持或者增加软件质量。
因此 软件再工程 是试图增加当前系统（或称遗留系统）
的总体质量、提高可维护性的工程。
21
软件再工程与新开发软件之间的重要差别表现在开发的起点上。再工程开始于已有的系统，通过改善原始系统的结构和产生新的系统文档，使之更容易理解、更易于维护。实施软件再工程的优越性是：
（ 1）减少重新开发软件的风险
（ 9）降低开发软件的成本再工程的成本比重新开发要小的多。
Ulrich(1990)引用了一个商业系统的例子：重新实现预算 5000万美元，经过再工程，仅用了 1200万美元，是重新开发费用的四分之一。
因此当一个系统有很高的业务价值同时需要很高的维护费用时，对该系统实施再工程是个经济的办法。
软件再工程过程中的活动主要包括以下几个方面：
22
文档重构 (redocument)? 结构重组 ( restructuring)
逆向工程 (reverse engineering)? 再工程 (reengineering)
23
1、文档重构对源代码进行静态分析，产生以下用图标和文本表示的信息：
构件的调用关系
类或构件的层次关系
数据接口表
数据词典信息
数据流图、控制流图、实体 -关系图、结构图
伪代码
测试路径
构件与变量的交叉引用图形、文本、表格信息用来帮助维护人员理解代码，
评估一个系统是否需要结构重组。
24
2、结构重组使用 CASE工具分析源代码，产生内部表示（语义网或有向图）并利用转换技术对内部表示进行精化，产生结构良好的系统代码。
3、逆向工程和文档重构一样，从系统的源代码中得出系统的说明和设计等信息，把这种信息求精与简化并储存成表格以被后用。逆向工程的关键在于它从详细的源代码实现中抽取出抽象说明的能力。对于实时系统，由于频繁的性能优化，
实现与设计之间的对应关系比较松散，设计信息不易抽取。
25
4、再工程是逆向工程的扩展。根据抽取出的信息，在不改变整个系统功能的前提下产生新的源代码。
（ 1）进行逆向工程,然后用当前新的方法对内部表示进行修改，以便详细说明和设计软件；
（ 2）纠正并完善软件系统模型；
（ 3）根据新的说明或设计产生新系统。
再工程过程的输入：
包括源程序文件、数据库文件、屏幕生成文件等与系统相关的文件。
再工程过程的输出：系统说明、设计、源程序等所有文档。
26
5、软件再工程的问题与前景 （ Pfleeger)
（ 1）需要自动化工具的支持有可以标识、分析并提出源代码中的信息的工具，但它们不能重构、获取及表达设计抽象这些没有直接表示在源代码中的信息。
（ 2）源代码中没有包含原设计的太多信息，缺失的信息必须从推论中重构。逆向工程的尝试最好是容易理解的、
稳定领域中出现的信息系统。
（ 3）在其他领域，只有用代码中隐含的信息、现有的设计文档、人员的经验以及问题域的全面了解，才能进行设计恢复。
（ 4）设计符号的形式化和领域模型的引入，将扩展我们理解与维护软件时用到的信息。期望转换技术的提高，支持更多的应用领域 并提高再工程的自动化
27
习题
1、什么是软件维护？分为哪几类？
2、软件生存期内为何维护的成本最高？如何降低软件维护的成本？
3、软件维护有哪些活动？如何进行维护后果分析？
4、软件的可维护性指什么？与可维护性相关的质量属性是什么？如何提高软件的可维护性？
5、请说明软件再工程的意义，与新开发软件有何区别？
软件再工程中有哪些活动？解释这些活动的含义。
2
第 5章 软件维护
软件维护的概念
软件维护的活动
软件的可维护性
软件再工程
3
6.1 软件维护的概念当软件系统在实际环境被用户使用时，软件开发宣告结束。但软件总是要变化的，在软件交付使用后修改软件的过程称为软件维护。
软件维护一般不包括重大的体系结构的改变，变更的实现方法一般是修改已有的系统构件以及在必要的地方添加新构件到系统中。
1、软件维护的分类
改正性维护：修改软件缺陷。
适应性维护：适应变更的操作环境（硬件、操作系统平台、其他支持软件）。
增强性维护：系统需求改变（机构因素、业务改变）。
4
Lientz和 Swanson(1980)对维护的工作量做过调查，
如图所示。 Nosek和 Palvia(1990)在十年后给出的数据与此相似。
适应性维护和增强性维护占了绝大部分工作量。维护是系统开发过程的自然延续，同样也涉及到需求描述、设计、实现和测试活动。
5
2、维护的成本维护成本和开发成本的比例在不同的应用域中是不同的。 Guimaraes(1983)的研究表明，对于业务应用系统，维护成本和系统开发成本大体相等。对于嵌入式实时系统，维护费用是开发成本的四倍以上。
带来高维护费用的关键因素：
人员的不稳定
合同责任
维护人员技术水平
系统结构衰退遗留系统的结构受到频繁变更的破坏；没有使用现代的软件工程技术开发；文档不全、不一致；没有采用配置管理，
系统变更时在寻找系统构件的合适版本上浪费时间。
6
Belady和 Lehman提出了一个计算维护工作量的模型：
M＝ p＋ K× e(c－ d)
其中 M：软件维护所有的工作量；
p：生产性工作量（分析、设计、编码及测试）；
K：经验常数；
c：复杂程度；
d：维护人员对软件的熟悉程度。
该模型描述了影响维护的诸多因素中重要的关系。如果一个系统开发没有遵循软件工程原则，软件结构不好，
c的值就会很高，再加上维护人员对软件的不熟悉,d的值很低。结果是，维护的成本呈指数级的增长。
7
如何降低软件维护的费用？
（ 1） 从开发阶段的一开始就按质量标准构建系统,给予,可维护性,属性以足够的重视,这样可以使系统的整个生命周期成本减少 。 下图说明了这个问题 。 系统 1在开发成本中多投入 $25000,用于提高系统的可维护性,结果在整个生命周期中节省了 $100 000的维护成本 。
8
（ 2）采用演化式的系统开发模型（如增量、螺旋），
建立能结合新需求而演化和变更的系统。
（ 3）实施软件再工程，改善系统结构，提高可维护性。
9
6.2 软件维护活动
Pfleeger和 Bohner(1990)提出了软件维护的一种模型，
其中包含了度量的反馈，见下图：
10
该图说明了当要求进行一项变动时要执行的活动，底部带标注的箭头代表提供的度量信息，管理人员利用这些信息决定什么时候和怎样进行变动。
维护活动：
（ 1）变更分析各种变更带来的的负面影响：
产生不正确或不完整的补丁软件、结构很差的设计与编码、构件不标准等等。
这些负面影响使软件复杂性增加，更不易理解。因此对变更的成本、影响要进行分析。
（ 2）理解变更，规划新版本根据变更的类型（缺陷修正、适应性调整或增加新功能），决定哪些变更在下一个版本中完成。
11
（ 3）实现变更分析系统变更的需求（如有必要，可对提出的变更建立原型），对系统构件重新设计，编码、测试。软件开发中重要的配置管理思想在这里同样适用。
对于紧急变更，保证更快速度完成比保证变更过程规范化更重要。
（ 4）后果分析维护活动中改动的是需求、设计与代码构件、测试用例以及文档等工作产品。一个工作产品的质量可能影响到其他工作产品,Pfleeger（ 1990）提出必须建立并跟踪工作产品之间的关系，帮助我们评估一个构件的变更对所有其他构件的影响。下图展示了工作产品之间的关系及可追踪性：
12
R1
R2
R3
Ri
D1
D2
D3
Dj
.
.
.
.
.
.
水平追踪连接
C1
C2
C3
Ck
.
.
.
T1
T2
T3
Tn
.
.
.
垂直追踪连接需求 设计 代码 测试工作产品的追踪图
13
其中：每个矩形框内的结点表示为该阶段产生的工作产品或构件。构件及之间的实线箭头构成了 度量产品的垂直跟踪图 。某一阶段内（矩形框内），在产品变动前后分别对以下度量指标求值：
结点总数、指向一个结点的边数（该结点的入度）、
一个结点发出的边数（出度）、环路数。
Pfleeger提出计算最小路径集，如果变动后覆盖的路径增加，或者结点的入度、出度增加，则系统会更复杂、
更难于维护。利用此信息，维护组可能决定用另一种方式实现或者取消该变动。
虚线箭头连接的图构成了系统的 水平跟踪图,代表了对变动的一个 过程的度量 。每一对工作产品：需求产品与设计产品，设计产品与代码产品，代码产品与测试用例，
在两者之间形成关系子图，度量规模和复杂性关系，从而得出负面影响。还可浏览整个水平跟踪图，了解变动后总的可追踪性变得更复杂还是简单了。
14
6.3 软件可维护性软件的可维护性、可靠性和可用性是衡量软件质量的几个主要特性，是用户最关心的几个问题。
软件可维护性可定性地定义为：维护人员理解、改正、
改动和改进这个软件的难易程度。
1、用于衡量可维护性的软件特性,
可用下面 7个质量特性来衡量：
可理解性、可测试性、可修改性、可靠性、可移植性、
可使用性 和 效率 。
对于不同类型的维护，这 7种特性的侧重点也不相同。
要将这些质量要求贯彻到各开发阶段的各步骤中。软件的可维护性是产品投入运行以前各阶段针对上述各质量特性要求进行开发的最终结果。
15
开发阶段 可维护性因素需求分析? 明确维护的范围和责任。
检查每条需求，分析维护时可能需要的支持。
明确哪些资源可能会变化以及带来的影响。
了解系统可能的扩展与变更。
设计阶段? 设计系统扩展、压缩或变更的方法（如将变动部分与稳定部分分离）。
做一些变更或适应不同软硬件环境的实验。
遵循高内聚、低耦合原则。
设计界面不受系统内部变更的影响。
每一个模块只完成一个功能。
16
编码阶段? 检查源程序与文档的一致性。
检查源程序的可理解性。
源程序是否符合编码规范。
测试阶段? 维护人员与测试人员一起按照需求文档和设计文档测试软件的有效性、可用性。
维护人员将收集的出错信息分类统计，为今后的维护奠定基础。
17
2、可维护性的度量
（ 1）使用质量检查表度量一个可维护性的软件的 7种特性。质量检查表是用于测试程序中某些质量特性是否存在的一个问题清单，检查者对表上的每一个问题，回答“是”
或“否”。
（ 2）间接地度量可维护性（面向时间的度量）：
察觉到问题所耗的时间；
分析问题所用的时间；
形成修改说明所需时间；
修改所用时间；
局部测试所用时间；
整体测试所用时间；
维护复审所用时间；
完全恢复所用时间。
有关设计结构和软件复杂性的度量也可间接说明软件的可维护性。
18
3、如何提高软件的可维护性
（ 1）建立明确的软件质量目标；
有一些特性是相互促进的，有一些是相互矛盾的，根据用途不同或计算机环境不同，确定最重要的特性。
（ 2）使用先进的开发技术和工具；
传统方法开发的软件结构紧密相关于所要完成的功能，
结构不稳定。
（ 3）建立明确的质量保证措施；
在各里程碑处检查与可维护性相关的软件特性。
（见下图）
19
分析 设计 编码 测试 验收 配置复审可靠性可移植性可用性可理解性可修改性可测试性可理解性可修改性可移植性效率可靠性效率 完整性一致性可理解性各里程碑处对与可维护性相关的软件特性的检查：
（ 4）选择易理解、易编程的语言，如 4GL ；
（ 5）建立完整、一致和正确的文档。
20
6.4 软件再工程在许多有大量软件的企业中，维护这些软件是一个挑战！
如一个保险公司使用多种实现语言在不同平台上支持许多不同的应用程序，例如有一个应用程序处理某种类型的保险单、保单持有人信息、保险统计与记帐信息。这样的保单可能要维持数十年。有时不到最后一个保单持有人死亡并且每一项索赔都得到支付，是不可能报废软件的。
这些软件有的已老化，虽然经常出错，但对业务处理提供了有力的支持。企业还要依赖这些系统，却很难决定怎样使这些系统更易于维护。其选择可能是扩充或者用新技术替换；每种选择都希望在成本尽可能低的情况下保持或者增加软件质量。
因此 软件再工程 是试图增加当前系统（或称遗留系统）
的总体质量、提高可维护性的工程。
21
软件再工程与新开发软件之间的重要差别表现在开发的起点上。再工程开始于已有的系统，通过改善原始系统的结构和产生新的系统文档，使之更容易理解、更易于维护。实施软件再工程的优越性是：
（ 1）减少重新开发软件的风险
（ 9）降低开发软件的成本再工程的成本比重新开发要小的多。
Ulrich(1990)引用了一个商业系统的例子：重新实现预算 5000万美元，经过再工程，仅用了 1200万美元，是重新开发费用的四分之一。
因此当一个系统有很高的业务价值同时需要很高的维护费用时，对该系统实施再工程是个经济的办法。
软件再工程过程中的活动主要包括以下几个方面：
22
文档重构 (redocument)? 结构重组 ( restructuring)
逆向工程 (reverse engineering)? 再工程 (reengineering)
23
1、文档重构对源代码进行静态分析，产生以下用图标和文本表示的信息：
构件的调用关系
类或构件的层次关系
数据接口表
数据词典信息
数据流图、控制流图、实体 -关系图、结构图
伪代码
测试路径
构件与变量的交叉引用图形、文本、表格信息用来帮助维护人员理解代码，
评估一个系统是否需要结构重组。
24
2、结构重组使用 CASE工具分析源代码，产生内部表示（语义网或有向图）并利用转换技术对内部表示进行精化，产生结构良好的系统代码。
3、逆向工程和文档重构一样，从系统的源代码中得出系统的说明和设计等信息，把这种信息求精与简化并储存成表格以被后用。逆向工程的关键在于它从详细的源代码实现中抽取出抽象说明的能力。对于实时系统，由于频繁的性能优化，
实现与设计之间的对应关系比较松散，设计信息不易抽取。
25
4、再工程是逆向工程的扩展。根据抽取出的信息，在不改变整个系统功能的前提下产生新的源代码。
（ 1）进行逆向工程,然后用当前新的方法对内部表示进行修改，以便详细说明和设计软件；
（ 2）纠正并完善软件系统模型；
（ 3）根据新的说明或设计产生新系统。
再工程过程的输入：
包括源程序文件、数据库文件、屏幕生成文件等与系统相关的文件。
再工程过程的输出：系统说明、设计、源程序等所有文档。
26
5、软件再工程的问题与前景 （ Pfleeger)
（ 1）需要自动化工具的支持有可以标识、分析并提出源代码中的信息的工具，但它们不能重构、获取及表达设计抽象这些没有直接表示在源代码中的信息。
（ 2）源代码中没有包含原设计的太多信息，缺失的信息必须从推论中重构。逆向工程的尝试最好是容易理解的、
稳定领域中出现的信息系统。
（ 3）在其他领域，只有用代码中隐含的信息、现有的设计文档、人员的经验以及问题域的全面了解，才能进行设计恢复。
（ 4）设计符号的形式化和领域模型的引入，将扩展我们理解与维护软件时用到的信息。期望转换技术的提高，支持更多的应用领域 并提高再工程的自动化
27
习题
1、什么是软件维护？分为哪几类？
2、软件生存期内为何维护的成本最高？如何降低软件维护的成本？
3、软件维护有哪些活动？如何进行维护后果分析？
4、软件的可维护性指什么？与可维护性相关的质量属性是什么？如何提高软件的可维护性？
5、请说明软件再工程的意义，与新开发软件有何区别？
软件再工程中有哪些活动？解释这些活动的含义。
