第十一章 软件维护
大约 20年前，软件工程人员对做完的程序将不再
关心，犹如过时的报纸，程序被束之高阁或弃而不
问。到 1988年，软件界第一次提出, 千年虫问题,,
工程人员不得不从洪水般的源代码中去寻找, 时间
变量, 。虽然，所需修改的仅仅是变量的类型或长
度，但在全球的软件行业中却掀起了巨大的波澜。
由此可见，软件投入运行后，进行一定的修改和
维护是必不可少的。软件维护是软件生命周期的最
后一个阶段,最长的一个阶段,也是最为重要的一个
阶段，软件维护工作的好坏直接影响到软件使用的
成功与否。
对于软件维护工作，我们要有正确的认识，其一、
从工作量的角度看，软件维护往往会花费软件开发
组织的大量时间，随着用户对软件需求的不断变化
及软件环境的改变，软件维护的工作量逐渐递增。
当今软件开发人员和维护人员匮乏，如何利用有限
的软件工程技术人员去满足节节攀升的软件维护需
求是一个亟待解决的严峻问题。其二、从资金投入
的角度看,软件属产品范畴，但又不同于普通商品，
软件在投入运行后需要追加大量的维护资金，投入
量大约是开发成本的四、五倍，甚至更高。
本章我们将主要谈谈软件维护的基本概念和软件
维护的过程，以及如何提高软件的可维护性、降低
软件维护的时间、经济成本和软件维护的发展趋势。
? 软件维护的基本概念
? 软件的可维护性
? 软件维护的过程分析
? 基于构件复用的软件再工程
第一节 软件维护的基本概念
一、软件维护的定义
所谓软件维护 (Software Maintenance)就是在软
件已经交付使用之后，为了改正错误或满足用户新
的需要而修改软件的过程。软件在投入运行之前，
往往要经过严格的测试，但事实表明，测试阶段不
可能完全暴露软件潜在的错误。同时，用户的需求
是发展的，软件能充分满足用户需求是软件工程人
员追求的最高目标，也是软件生命力所在。
据, 美国程序员, 杂志 1995年 7月提供的统计资
料，全球大约 5/6的软件项目存在失败的部分。所以，
软件维护是任何软件生命周期必不可少的阶段，忽
视软件维护的软件工程是盲目的、危险的。
当今信息技术发展迅猛，计算机软硬件的升级频
率越来越快，网络等通讯技术突飞猛进，增加了软
件系统环境的复杂性，也使软件维护的方式产生了
根本性的变化。诸如电话提供解决方案、定期上门
维护和网上指导性维护等方式已经逐渐成为当今软
件维护的主要方式。
二、软件维护的分类
ANSI/IEEE在 20世纪 80年代从软件维护类型的角
度给出了软件维护的定义：, 软件维护是指软件成
品提供使用后，为了修改差错、改善功能和性能、
适应环境变化而进行的软件修正。, 这个对软件维
护的定义给出了软件维护的分类。
软件维护通常包括四类：
? 为了纠正在使用过程中暴露出来的错误而进行的
改正性维护；
? 为了适应外部环境的变化而进行的适应性维护；
? 为了改进原有的软件而进行的完善性维护；
? 以及为了提高可维护性和可靠性而进行的预防性
维护。
(一 )正确性维护 （ corrective maintenance）
正确性维护又称改正性维护，其主要任务是完成
软件潜在错误的改正。
（二）适应性维护 (adaptive maintenance)
适应性维护指为适应软件的外界环境变化而进行
的修改,它是由软件生存的环境变化引起的。任何系
统总是存在于一定的环境之中，环境与系统相辅相
成、相互作用。
对软件来说，环境变化源于以下几个方面：
(1)用户需求变化。 随着企业业务的不断变化
和发展，原系统业务流程图已不能准确描述现有企
业业务状况，因此，既存软件系统已经无法完全满
足用户的需求，原系统的数据变量定义和相关算法
要做适当修改。例如，国家税费调整、电话区号调
整及千年虫问题等等。
(2)软件环境的变化。 其一,硬件和操作系统
更新。软件运行的平台变化是软件适应性维护的主
要因素之一。由于硬件的更新换代，拓宽了软件的
运行空间，为软件运行效率的提高提供了基础，不
对软件进行适应性维护将对硬件资源造成巨大的浪
费。同时，高版本操作系统的推出，导致了大量应
用型软件与操作系统的冲突，必须对现有软件进行
适应性维护。 其二,系统运行环境的变化。如由主
机方式变为客户 /服务器方式，由客户 /服务器方式
变为 Web方式，这时的系统体系结构必须做相应的改
变。
(3)开发环境的升级 。 譬如现在常用的 VC++、
PowerBuilder等开发环境的升级换代如同操作系统
一样频繁发生，这样也会对系统提出适应性维护需
求。
（三）完善性维护 (perfective maintenance)
完善性维护指为扩充系统的功能和改善系统性能
而进行的修改，一般包括增加或修改功能，提高系
统的安全性、处理能力等任务。完善性维护通常需
要用户领域的介入，并且是一个带反馈的反复的功
能追加过程。从现实情况来看，现阶段软件维护的
主要形式是完善性维护，据有关统计数据表明：全
部维护活动的 50%到 70%是完善性维护。
完善性维护的的一般模型
(四 )预防性维护 (preventive maintenance)
预防性维护是为减少或避免以后可能需要的前三
类维护而对软件配臵进行的工作，通过再结构化、
再标准化等系统优化方法，提高系统的可维护性，
对文档进行维护，对数据进行重组。预防性维护有
较强的前瞻性，而且做好预防性维护工作能降低或
避免因为维护工作不充分、不及时导致软件系统瘫
痪带来的灾难性后果。
随着网络及通讯技术高速发展，我们对软件维护
又提出了新的要求。网络环境下软件的安全问题、
软件遭受黑客攻击及病毒破坏后的软件系统的恢复
工作也纳入软件维护的范畴。所以也可以这样说，
软件维护是指软件在交付使用后，为了使软件能正
常工作、修改潜在错误和满足用户新需求的一系列
对软件的修改及复原工作。
三,软件维护的内容
软件维护工作一般发生在客户使用软件产品的过
程中，由软件维护的分类可以看出，软件维护工作
一般由软件的用户和软件开发人员（或专职软件维
护人员）共同完成。其主要内容包括如下几点：
（一）程序维护
程序维护是指根据使用的要求，对程序进行全部
或部分修改。程序维护的最终目的是满足用户的需
求，对传统的软件工程而言，程序维护要修改用户
需求的概念模型和详细设计，并对源代码进行重新
修改，所以工作量较大且容易对原有功能产生破坏，
这是程序维护中不可忽视的一个问题。另外，根据
需要进行修改以后，必须书写修改设计报告。修改
设计报告必须和源代码同时维护，只有与程序完全
一致的修改设计报告才是真正有价值的文档。
（二）文件备份及修复
文件备份及修复属于数据维护的范畴，包括安装
与转换新的数据库出现异常或溢出时的补救和维护
工作。我们知道，对计算机系统而言，无论是硬件
系统或软件系统都有其脆弱性，所以如何提高其可
靠性一直是我们研究的重要课题。定期进行文件和
数据的备份和异常情况下的数据修复是提高软件可
靠性的一个有效手段。
（三）查杀病毒
计算机病毒对计算机软件的正常工作造成巨大
的威胁。一九八三年计算机病毒首次被确认，当时
人们并没有引起足够的重视。我国于一九八九年在
计算机界发现病毒。现在，全世界已发现数万种病
毒，并且还在高速度增加。由于计算机软件的脆弱
性与互联网的开放性，我们将与病毒长久共存。病
毒正朝着能更好的隐蔽自己并对抗反病毒手段的方
向发展，同时其破坏性越来越强,CIH病毒开创了对
硬件严重破坏的先河。对用户来说，要加强软件系
统的可靠性，查毒杀毒是软件维护阶段必不可少的
一个环节。降低病毒危害最有效的两个方法是：缩
短数据备份周期和加快杀毒软件的升级频率。
（四）硬件维护
硬件人员应加强设备的保养以及定期检修，并做
好检验记录和故障登记工作。虽然，硬件维护严格
意义上不是软件维护的范畴，但是没有硬件的强有
力的支持，软件就失去了运行的平台，硬件维护是
软件维护的基础工作。硬件维护包括评估现有硬件
设备、检测系统老化程度和运行状况、确定升级方
案和购买方案等等。
（ 五 ） 系统优化
系统优化是从系统全局出发，协调系统内部各组
成单元之间的连接关系，使整个系统按预定目标在
整体上达到最优。现在的软件不管操作系统还是应
用软件，随着其功能扩充与增强，变得越来越臃肿、
缓慢，我们还是只能忍受着，因为不管怎样，我们
必须要用它。鉴于此，我们要采用不同的优化方法，
针对不同的系统、不同的环节来采用不同的优化策
略。
四, 软件维护的特点
软件维护工作是一个变化的过程，这是由于软件
生存的内部环境和外部环境的变化引起的，任何企
业业务不可能较长时间的不变化，所以，软件系统
需要随着企业业务及管理模式的变化而进行适当调
整。当然，软件维护不同于计算机硬件或网络产品，
它有自己的维护特点。
（ 一 ） 软件维护耗时费力
软件维护是一项非常耗时、耗精力的工作。由于
现代企业的发展速度快，业务内容及业务流程不断
变化，用户不断追加功能需求。这样，软件维护的
周期大大缩短，软件开发人员必须投入大量的人力、
物力和财力去从事软件的维护工作。另外，软件用
户计算机应用的能力及熟练程度不同，造成用户对
软件的使用情况参差不齐，本来应该在软件培训阶
段完成的工作又要在维护阶段再一次提出来。
近期的调查报告发现软件工程 20%的工作量用在
开发上，而 80%用在维护上。但是，如果对于软件的
频繁修改、排错和功能追加，加上没有规范的管理
手段、有效的方法和技术，可能很快就会导致软件
结构的混乱和质量下降，最终结果是软件的夭折或
提前报废。
（ 二 ） 软件维护的代价昂贵
回顾软件业发展的历史，我们不难看出，软件维
护的费用所占软件工程总费用的比重节节攀升。从
1970年到 1990年的 20年间，比重成倍增加，达到 80%。
软件维护的代价是多方面的，除了经济方面的代价
外，软件维护还可能导致用户对软件开发人员的不
信任或不满；软件维护的改动，会破坏原有系统的
完整性，引入潜在错误，降低了软件质量的可靠性；
同时，当今软件开发人员的短缺是导致软件危机的
原因之一，软件维护工作花费了软件工程师的大量
时间和精力，使软件的生产率无法提高。
（ 三 ） 远程维护是现代软件维护的新途径
通讯和网络技术的发展为软件的维护提供了便捷
的方式。软件使用中会出现各种各样的问题，其中
有的问题可以通过电话,E-mail、在线交谈和视频
指导等方式加以解决。还有一部分问题，由于用户
对软件的开发环境不熟悉，维护人员对用户的使用
情况又不了解，所以维护人员必须看到问题发生的
实际情况才能解决。
如果软件维护人员到用户的单位去，这样既浪费
了时间又给用户添加了经济负担。 Symatec公司推出
的 Pcanywhere软件可以把用户的软件使用实际情况
再现于维护人员的计算机上，维护人员可以实现远
程维护。
Pcanywhere软件提供了文件传输, 远程控制和远
程网络需求的总体解决方案, 它具有如下功能：
1,Pc---Pc的远程控制
2,文件传输
3,运用远程网络连接使一台电脑成为网络中
的工作站
当然, 基于 WEB的多媒体软件维护系统也是现代
经常使用的一种软件维护方式之一 。
（ 四 ） 软件复用技术简化了软件维护
软件的复用以构件为基本单位，构件是可以明确
辨识的构成成分，软构件指在软件系统中具有一定
意义的相对独立的软件构成成分。特别是完善性维
护需要的正是可以被其它软件系统复用的、具有相
对独立功能的系统构成成分。基于构件的软件工程
的兴起、构件库的建立与维护越来越受到软件工程
师的重视，我们可以展望，在不远的将来，完善性
维护工作将更加简单化、产业化和自动化。
结构化维护与非结构化维护差异明显
对结构化维护而言, 起点是评价设计文档, 维护
步骤如下：
1,确定软件结构特点；
2,性能特点分析；
3,接口特点分析；
4,估量改动带来的影响；
5,计划实施途径；
6,修改设计并仔细复查；
7,编写相应的源代码；
8,进行回归测试；
９．交付使用。
然而, 非结构化维护的起点是评价程序代码,
其主要特征是难于评价软件结构, 全程数据结构,
系统接口和代码改动的后果 。 非结构化维护的步骤
如下：
1,分析用户需求；
２, 代码评价；
３, 评价反馈；
４, 重编程序；
５, 复查 （ 含重编程序反馈 ）
６, 交付使用 。
从两种维护的方式可以看出，非结构化维护以浪
费大量的精力为代价，原因是没有使用良好定义的
方法论来开发软件；相反，结构化维护能够使维护
工作井然有序，减少时间和精力的浪费，并且提高
软件维护的质量。
第二节 软件的可维护性
一,软件的可维护性
软件的可维护性是指软件能够被理解、改正、适
应和完善，以适应新的环境的难易程度。可维护性
的好坏是衡量一个软件工程成功与否的重要参数，
而且在软件开发的每一个阶段可维护性都是一个不
容忽视的问题。事实表明，目前现有的很多软件维
护工作开展困难甚至无法进行，原因是多方面的，
但有一点是共性，原有软件的可维护性较差。软件
可维护性研究的主要目的就是提高软件维护的可能
性，降低维护的花费，并把软件维护人员从繁琐的
维护工作中真正解放出来。
二、软件维护中问题
与软件维护有关的绝大多数问题的根源在于计划
阶段和开发阶段的工作有缺点,可以这样说，软件的
开发阶段潜在的错误和设计、规划的不合理是软件
维护阶段问题出现的根本原因。实践表明，绝大多
数的软件工程的软件维护阶段均会不同程度的出现
如下典型问题：
? 程序的源代码或算法可读性差，加大了软件维护
的难度。
? 文档丢失或文档不全。
? 软件的开发人员和软件维护人员分离，软件维护
的逆向工程花费软件维护人员的大量时间和精力。
? 软件本身可修改性差，无法二次开发。
? 开发方和出资方对软件维护的认识不足，资金追
加不够，软件维护工作无法深入。
? 软件维护工作繁琐，时间长，影响软件的正常使
用，容易导致用户对软件维护人员和软件系统的不
信任。
软件开发人员在软件开发过程中应该力求避免软
件维护阶段出现的问题。软件开发的工程化、软件
管理的科学化有助于解决与软件维护有关的若干问
题，所以，增强软件的可维护性是软件工程人员在
软件开发全周期必须时刻考虑的一个重要问题。
三、软件可维护性的决定性因素
软件生命周期每个阶段的工作都和软件可维护
性有密切的关系。良好的设计、完善的文档资料以
及一系列严格的复审和测试，使得一旦发现错误比
较容易诊断和纠正。因此，在软件周期的每个阶段
都必须充分考虑可维护性问题，并且为软件维护作
好准备。从软件自身的角度看，软件的可理解性、
可测试性、可修改性和可移植性是决定软件可维护
性的基本因素。
（一）文档的健全性
文档是影响软件可维护性的最重要因素，有时甚
至比可执行代码更为重要。文档可分为用户文档和
系统文档两大类。不管是哪一类文档都必须和源代
码同时维护，只有与程序完全一致的文档才是真正
有价值的文档。
(二 ) 可理解性
可理解性表现为外来读者理解软件的结构、接
口、功能和内部过程的难易程度。我们知道，现在
算法描述的工具和编程语言种类繁多，短时间内不
可能实现完全统一，所以模块化、详细的设计文档、
结构化设计、源代码的内部文档等都是增强软件可
读性和可理解性的有效方法。
（三）可测试性
可测试性是对软件正确性论证的容易程度。软
件工程中，软件修改和测试的难易程度主要取决于
软件容易理解的程度。
（四）可修改性
可修改性是指软件容易修改的程度，这里的修
改主要针对源代码或有关文档。软件的可修改性和
软件设计原则直接有关。可修改性好的软件在维护
时出现连带错误的概率相对较小。
（五）可移植性
随着面向对象的软件工程和基于构件的软件工程
技术的发展，软件的可移植性也成为衡量软件可维
护性的一个重要方面。可移植性指软件的部分程序
和某些模块转移到另一个计算机环境中去并能发挥
功能的可能性。可移植性强的软件不依赖于具体的
计算机环境，可以在不同的计算机和操作系统中正
常工作。
影响软件可维护性的几个因素是紧密相关的。没
有健全文档的软件维护几乎无法进行；维护人员在
正确理解一个程序之前根本不可能修改它；如果不
能进行完善的诊断和测试，则表面正确的修改可能
引起其他故障；可移植性强的程序往往可以进行单
独测试，也便于软件整体的修改维护。
因此，在软件开发的各个时期，我们应该把软件
的可维护性作为一个关键目标。只有这样才能保证
软件在较长的时间内能正常运行，即使有维护需求，
也能在较短时间内实现软件的维护，从而保证软件
有较好的可用性。
四、软件开发各阶段的可维护性要求
软件的维护是软件工程的最后一个阶段，指在软
件交付使用之后为保证软件能正常运行所进行的一
系列后期工作。但是，软件的可维护性贯穿软件开
发的各个阶段，没有各阶段可维护性保证，交付使
用的软件根本不可能实现维护。在软件开发的各阶
段应注意如下方面：
（一）需求分析分阶段：
对用户潜在的需求进行分析并留有实现的空间；
对将来可能改进的部分和可能会修改的部分加以注
意并指明；应该考虑软件的可移植性问题，软件的
复用可以增加软件的可维护性和降低软件维护工作
量；考虑可能实现软件维护的系统体系结构。
（二）设计阶段：
在设计阶段，代码冗余设计、编写健全的文档等
都与可维护性相关；应该从容易修改、模块化和功
能独立的目标出发；设计中应该对将来可能修改的
部分预先做准备。
（三）编码阶段：
编码阶段编码风格和内部说明文档是影响可维护
性的两个重要因素；不同的程序设计语言编写的程
序可维护性不同，一般情况下，高级语言的程序比
低级语言程序易于维护。同样是高级语言，各自的
可理解性也不同，目前看来，非过程化语言和面向
对象的语言较容易维护
（四）测试阶段：
软件测试实现预防性维护，检查所有的软件配臵
是否完整和可理解。
（五）维护阶段：
在完成每次维护工作之后，要修改源程序、设计
文档和用户手册。单纯的源代码修改会给以后的软
件维护带来障碍，产生严重的后果。
五、软件文档对软件可维护性的意义
良好的可维护性可以更快、更好地解决软件技术
问题；提高软件运行的性能和可靠性；为了从耗时
费力的软件维护问题中解放出来，降低用户软件运
行成本，减少混乱或瘫痪的时间，我们有必要进一
步研究以提高软件的可维护性。然而，软件文档对
软件的维护具有举足轻重的作用，软件文档是软件
维护的入口。
（一）软件文档的定义
软件文档是对软件总目标软件各组成部分之间的
关系、软件设计的策略和软件运行过程的历史数据
的说明和补充。软件本身不属于软件文档范畴，但
是文档和软件的源代码同样重要，缺一不可，相辅
相成。
（二）软件文档的内容要求：
系统使用说明书
系统安装和管理说明
系统需求和设计说明
系统的实现和测试说明
（三）软件文档的分类：
（ 1） 用户文档的内容：
功能描述,说明系统功能
安装文档,说明如何安装系统以及硬件配臵
需求。
使用手册,简要说明如何使用系统
参考手册,描述用户可以使用的所有系统设
施以及它们的使用方法。解释系统可能产生的各种
出错信息的含义。
操作员指南,说明操作员应该如何处理使用
中出现的各种情况。
（２）系统文档的内容：
系统文档是指从问题定义、需求说明到验收测试
计划等一系列和系统有关的文档。
软件维护费用在软件产品的开发费用中占了很大
一部分，应该说是最难的工作，开发人员最不愿意
作的工作，特别是在没有文档的情况下。要想提高
维护效率，首先开发过程中各种文档一定要齐备、
同时要保持与代码的同步，此外代码书 写过程中遵
循一定的规则（命名、注释等）。有了这两部分，
维护工作就不会无 处下手了。
第三节 软件维护的过程分析
一、软件维护的管理体系
维护工作中最常见的问题是错误扩散，主要包括
纠错性错误扩散与完善性错误扩散。因此，软件维
护需要建立一套完整的、科学的管理体系，即维护
管理体系。
对于产品的维护不能随便进行，要求建立申请 —
— 判断 —— 实施 —— 检查的过程，也就是任何维护
工作都要向有关部门申请，相关部门判断决定是否
实施及实施优先级，维护完成后还需要检查确认，
维护工作都要有记录。
在纠错过程中，往往纠正了这里的错误又引发了
其它地方发生错误，特 别是全局性的函数、变量、
过程、结构体的修改一定要慎重，此外各种接口的
修改也要慎重，千万不要引发其他的错误。完善性
维护增加了新的功能，也增加了 出错的可能，对此
一定要反复测试，最基本的要求就是不要破坏已有
的正常功能。维护活动完成后，一般要进行回归测
试，回归测试完成后才可交付用户使用。其具体过
程如下图：
软件维护管理体系
然而，如何实现新旧系统的转换呢？到底是直接
取代用户现在使用的老系统，还是新旧两套一起并
行运行呢？如果系统不是很重要，则可以马上取代
旧系统，应用修改过的新版本；如果对用户利益重
大则最好新旧一起用，互相参照监督，防止新版本
出现了老版本没有的问题，直到用户确认了新系统。
维护版本交付前，涉及软件的数据库等相关资源都
要备份，保证安全。
二, 软件的维护过程
（ 一 ） 建立维护组织
软件维护组织不是一个正式的常设组织，往往是
根据维护要求的提出而临时成立，它是一个为实现
软件维护而成立的人员团体。软件维护组织通常由
用户、技术员、维护管理员、高级系统管理员和局
部系统管理员组成，如下图所示：
软 件 维 护 组 织
原 软 件 系 统 +维 护 需 求
用 户 技 术 人 员 维 护 管 理 员 各 级 系 统 管 理 员
维 护 后 的 软 件 系 统
（二）编写维护报告
首先，我们要获得用户提出的维护需求，其方法
可以让用户填写用户维护申请表。维护需求有四类，
不同的维护需求表述的方式不同。对适应性和完善
性的维护需求，用户应该给出尽可能简洁的、准确
的需求描述。改正性维护往往是由于遇到软件运行
的错误，则用户必须详尽的描述错误发生的原因、
导致的相关后果，以及错误发生时软件运行的环境。
软件维护报告申请表设计如下图所示：
软 件 维 护 申 请 表
申 请 表 编 号, 申 请 日 期, 年 月 日
项 目 编 号 项 目 名 称
维
护
类
别
软
件
维
护
硬
件
维
护
改 正 性
完 善 性
适 应 性
预 防 性
系 统 设 备
外 围 设 备
问 题 说 明,
维 修 要 求,
维 修 优 先 级
申 请 人
维 护 方 式 远 程 /现 场
申 请 评 价 结 论,
评 价 负 责 人, 评 价 时 间,
软 件 维 护 申 请 表
根据用户给出的维护需求描述（表格或说明书），
软件组织要给出针对用户提出的维护需求的软件修
改报告，软件修改报告的内容比软件维护申请报告
的批复要详细。软件维修报告要求给出维护工作量
需求、维护要求的性质和与修改有关的数据。软件
修改报告交系统变化授权人审查后生效，软件组织
可以进行下一步详细的软件修改计划的制定和软件
修改的实施。
（三）进行软件修改
软件的维护是对正在使用的软件进行修改，它对
软件系统的正常使用造成影响，所以在软件修改实
施前必须提交申请报告。获准的对软件的修改才是
合法的，软件修改的主要内容和步骤如下：
(1)由系统管理员提出软件修改请求报告；
(2)由有关领导审批请求报告；
(3)源程序清单存档；
(4)手续完备后，实施软件的修改；
(5)软件修改后形成新的文档资料；
(6)发出软件修改和使用变更通知；
(7)进行软件修改后的试运行；
(8)根据运行情况作总结调整并修改文档资料；
(9)发出软件修改后，正式运行通知；
(10)软件做新的备份，并同定稿的文档资料一起
存档，这里的文档主要应包括以下内容：
维护的审批人、提请人、维护人的姓名、维护时
间、修改原因、修改的内容、修改后的现状。
（四）保存维护记录
为了能正确的计算软件维护的代价，评估维护技
术的有效性，我们要求完整的保存维护记录。维护
记录作为重要的文档为再次软件维护增强了可维护
性。维护记录的保存到底选取哪些数据呢？
Swanson提出了十八点内容：
1,程序标识；
2,源语句数；
3,机器指令条数；
4,使用的程序设计语言；
5,程序安装的日期；
6,安装程序后运行的次数；
7,安装程序后失效的次数；
8,程序变动的层次和标识；
9,因为程序变动而增加的源语句数；
10,因为程序变动而删除的源语句数；
11,每个改动耗费的人时数；
12,程序改动的日期；
13,软件工程师的名字；
14,维护要求表的识别；
15,维护类型；
16,维护开始和完成的日期；
17,累计用于维护的人时数；
18,与完成的维护相联系的纯效益。
以上 18条是保存维护记录的主要内容，可以针对
具体的维护状况适当增减记录的数据。总之，维护
记录的保存是为了健全文档，便于维护代价的计算、
维护技术的评估和增强软件的可维护性。
（五）评价维护结果
这是软件维护的最后一个阶段，其主要目的是对
维护的结果进行评价。维护结果的评价建立在相关
数据的基础之上，所以，维护的档案记录要做好。
根据档案记录的数据可以对维护工作做定量的计算
和评估。软件维护的评估可根据保存的维护记录从
七个方面进行，如下图所示：
软件维护定量评价方式
二, 软件维护引起的系统价值变化
计算机系统的组成分两大类，一是硬件系统，另
一个是软件系统。软件系统由系统软件和应用型软
件组成。软件维护对硬件的价值不发生影响，但是，
随着硬件技术的飞速发展和硬件设备生产的规模化，
硬件的更新加快而且价格的下降趋势迅速。
再者，操作系统平台的升级换代周期越来越短，
换代比例越来越高。半个世纪以来，大部分软件资
产并没能像硬件那样频繁地经历彻底的更新换代，
为了适应硬件的飞速换代，环境适应性维护周期也
越来越短，范围越来越大，加之用户的需求变化，
完善性维护的频率越来越快。软件维护的人、财、
物的投入必影响计算机系统的价格构成。从软件的
价值随着生存期而递增的特点来看，这并不违背市
场经济的价值规律。随着维护的深入，软件价值总
体呈递增趋势。软件维护对系统价值的构成的影响
情况如下图所示：
20多年前曾有人预言：软件进入维护期的比例将
随软件递增率一起增长，进入 21世纪后将有 80%的软
件人员从事维护性开发。由此可见，软件财富的绝
大部分是由软件维护阶段创造的，那么应该重视软
件维护，提高软件运行的可靠性，实现软件维护的
真正目标。
价值
系统生存周期
硬
件
价
值
软
件
价
值
硬
件
价
值
原
软
件
价
值
追
加
价
值
A
硬
件
价
值
原
软
件
价
值
追
加
价
值
A
追
加
价
值
B
原有软硬件价值比 A 次软件维护后价值比 B 次软件维护后价值比
软件维护对系统价值比的影响
第四节 基于构件复用的软件再工程
几十年来，硬件发展速度和更新换代的周期呈指
数型递增，而软件生产率表现为螺旋形发展，总也
追不上硬件。同时，社会对软件的需求飞速增长，
软件的开发能力不能满足社会需求的矛盾越来越突
出。因此，以软件复用（ Software Reuse）和软件
构件 (Software component)为核心的软件再工程方
法应运而生。
软件再工程（ Software Re-engineering）是指
对既存对象系统进行调查，并将其重构为新形式代
码的开发过程。最大限度地重用既存系统的各种资
源是再工程最重要的特点之一。显然，软件再工程
的关键技术是软件复用，软件构件是再工程的核心
与基础，也是软件复用的基本单位。我们认为，软
件再工程是未来一段时间软件工程的主流，它是解
决软件维护的有效手段，也是软件生产率提高的最
佳方式之一。
一, 软件再工程的起源
软件产品在其有限的生命周期后将会失去其原有
的功能与市场，虽然不同于日常生活中的普通商品
给环境带来巨大的污染，但是我们认为，只有可以
经过加工再利用的产品才能称为, 绿色的环保的产
品, 。现阶段，一面是人们日夜增长的软件需求，
一面是软件的开发能力相对不足，大量的既存软件
系统被弃之不用，带给人们的是巨大的资源浪费。
与其它的商品不同，越是庞大的、历史悠久的软
件系统越是宝贵的无形遗产。对既存软件系统的浪
费就是对宝贵遗产的损害，有人说，继承过去是软
件的立身之本，身后的历史越长，前面的路就越宽。
如果我们能轻松的重用过去，就能使软件工程产生
一次巨大的飞跃。
二, 软件再工程的定义
软件危机导致了软件再工程的产生和发展。软件
再工程的主要任务是优化软件体系结构，增强软件
的可维护性和可移植性，提高软件产品的生产效率
和产品质量。 Linda H.Rosenberg博士这样定义了软
件再工程：, 软件再工程是为了以新的形式重构已
经存在的软件系统而进行的检测、分析和更替，以
及随后的对新形式的实现, 。
三, 软件再工程的过程模型
软件再工程是一个过程，但不同于传统软件工程。
再工程经过抽象、改造、精化三个阶段，其过程可
以用下图描述：
基于构件的软件再工程的一般模型
现存系统
源代码
原概念世
界 改造
用户世界
用户需求
目标概念
世界
目标系统
源代码
抽象
构件库
精化整合
构件实例
搜索引擎
可见，软件再工程的过程源于源代码，以构建目
标系统源代码为终点。通常，我们把从现存系统的
代码分析、结构设计、实际需求分析到抽象出概念
世界的过程称为逆向过程，因为它与传统软件工程
的开发过程相反。在改造阶段，往往考虑到对系统
新功能的添加，需要用户领域的介入。
另外，我们把从目标概念世界到实际需求分析、
结构设计和目标源代码的生成过程称为正向过程。
所以说，软件再工程实际上属于软件生命周期中软
件维护的范畴，这种维护的主动性更强，它不是单
纯的改正性维护，相反，它是注重适应性、完善性
和预防性的维护。
四、软件构件
（一）构件的定义
相对系统而言，构件是可以明确辨识的构成成分，
软构件指在软件系统中具有一定意义的相对独立的
软件构成成分。软件再工程需要的正是可以被其它
软件系统复用的、具有相对独立功能的系统构成成
分。
（二）构件模型
一般情况下，构件由构件规约与构件实现两部分
构成。构件规约主要由构件模型来进行描述，给出
构件的本质特性。目前国内外已经形成许多构件模
型，诸如３ C模型,CORBA模型和青鸟构件模型等等。
它们几乎都详尽地描述了构件的名称、功能、对外
接口和相关参数化属性，向构件复用者提供了关于
构件的大量信息。当然，有时候构件的内部结构对
于构件的有效复用也是必不可少的。构件实现由构
件的生产者完成，复用者可不去关心它的细节，对
复用者而言，关键是构件模型中的构件规约。
对大量的构件进行有效的、科学的管理和建模，
以期方便构件的存储、检索、推理，是成功复用构
件的保证。在此，我们着重于构件描述、构件分类
和构件库组织的讨论与研究，它们也是构件建模的
核心内容。
五、构件模型的描述与构件复用方法研究
从软件再工程的角度看，构件描述是对构件本质
的抽象描述，为构件的制作和复用提供依据；从构
件模型的角度看，诸如实现方式、实现体、关联构
件、大小和生产日期等等信息也是构件模型的具体
内容。在此，我们介绍几种构件模型的描述的方法：
（一）构件模型的特征向量法
对于任意构件 X的所有属性 {a1,a2,…,ai,…,an}
采用向量法描述：
〈 a1(x),a2(x),…,ai(x),…,an(x)〉 ；
ai及 ai(x)是属性 -值的对偶。在构件的相似性研
究中，可以把任意构件看作 n维空间中的一个点。显
然，匹配任务转化为求解在 n维空间中与给定点距离
最近的点的问题。
给定的构件 X与构件库中的任意构件 Y的相似度可
以通过欧氏距离或麦考斯距离求得。针对事实上单
个属性对整体上的相似度有不同贡献，可以用带权
麦考斯距离求解目标构件和构件实例的相似度。很
显然，最大相似度的构件实体的获得需要全体构件
实例和理想构件的比较，这依赖于大量运算，算法
效率较低。
因此，我们提出一个改进的求解算法，在构件模
型采用特征向量描述的条件下，考虑便于实现构件
自学习和构件匹配算法，根据用户给出的理想构件，
把其属性分解为前臵属性和后续属性，从构件库中
获取与理想构件模型完全或部分匹配的构件实例。
如下图所示：
构 件 特 征 向 量 表 示 法 的 匹 配
res1
res2
pre1
pre2
pre3
pre4
pre5
res
res1
pre_x1
pre_x2
构 件 实 例
目 标 构 件
（ 2）构件模型的语义表示法
这种模型以语义为核心，给出构件的结构模型。
构件的结构模型约定了构件的组成，它是对构件实
体的抽象。对构件而言，它能提供一些功能，同时
其功能的实现以一定的所需构件为基础。为此，我
们必须给出构件的接口，用于描述通讯约束和构件
间通讯实现。其次，我们要给出对构件的功能和属
性的语义描述，语义描述的主要内容是构件的含义
和使用方法，它最终决定构件的复用价值。构件接
口的标准化实质上是构件语义形式化描述措施的一
个重要方面。
除此以外，还有前臵和后续条件定义操作、命名
服务中命名和命名上下文标准、目录和目录上下文
标准、事务服务描述符、部署描述符等，同时有命
名规则、目录和命名绑定规则、事务语义定义、资
源分布部署说明等。在不同标准中，它们都有自己
的形式化语义规定。基于语义的构件结构模型如下
图所示：
实 例 集
构 件 属 性 抽 象
构 件 功 能 抽 象
接 口 体 集 合 语 义 体 集 合 实 现 体 集 合
基 于 语 义 的 构 件 结 构 模 型
成功的软件构件复用需要对构件功能在语义上有
精确的定义，还需构件在特定使用环境中得到质量
和可靠性认证。没有这些保证，复用将是不可预见
的和冒险的。基于语义的构件模型表示如下：
构件,:＝ <规约，实现 > /*实现对装配透明 */
规约,:＝ <接口规约，结构规约 >
接口规约,:＝ <提供功能集，要求功能集 >
机构规约,:＝ <原子构件规约 >∣ <复合构件规约 >
构件的语义模型的建立促进了构件的描述和构件
组装的实施，为构件的检索、评价、剪裁和扩展奠
定了坚实的基础。
六、软件复用的前景
构件技术已经成为当今计算机领域的重要组成，
许多常用的开发工具提供了对不同构件模型的实现
支持，特别在一些分布式软件系统中，已经把软件
的构件化作为解决维护、扩展和升级的一种重要手
段；同时，伴随着用户对既存软件系统的需求递增，
在现在及将来的一段时间内，软件再工程进一步发
展还需要强大构件库支撑。
构件数据库的建立对构件复用具有重大意义，它
是用户或软件开发组织的一笔宝贵财富，构件可以
来源于历史上开发的软件模块，关键是在开发过程
中注意收集软件模块以及其完整的文档资料。另外，
其实构件可以迈向商业化道路，作为商品在市场上
流通，促进再工程的实施。但是，要使基于构件的
软件再工程成为现代软件工程的主流，构件的建模
还要在降低构件之间的相关性和提高构件内元素之
间的相关性等等方面作进一步研究，当然这本身也
是软件维护研究的课题。
大约 20年前，软件工程人员对做完的程序将不再
关心，犹如过时的报纸，程序被束之高阁或弃而不
问。到 1988年，软件界第一次提出, 千年虫问题,,
工程人员不得不从洪水般的源代码中去寻找, 时间
变量, 。虽然，所需修改的仅仅是变量的类型或长
度，但在全球的软件行业中却掀起了巨大的波澜。
由此可见，软件投入运行后，进行一定的修改和
维护是必不可少的。软件维护是软件生命周期的最
后一个阶段,最长的一个阶段,也是最为重要的一个
阶段，软件维护工作的好坏直接影响到软件使用的
成功与否。
对于软件维护工作，我们要有正确的认识，其一、
从工作量的角度看，软件维护往往会花费软件开发
组织的大量时间，随着用户对软件需求的不断变化
及软件环境的改变，软件维护的工作量逐渐递增。
当今软件开发人员和维护人员匮乏，如何利用有限
的软件工程技术人员去满足节节攀升的软件维护需
求是一个亟待解决的严峻问题。其二、从资金投入
的角度看,软件属产品范畴，但又不同于普通商品，
软件在投入运行后需要追加大量的维护资金，投入
量大约是开发成本的四、五倍，甚至更高。
本章我们将主要谈谈软件维护的基本概念和软件
维护的过程，以及如何提高软件的可维护性、降低
软件维护的时间、经济成本和软件维护的发展趋势。
? 软件维护的基本概念
? 软件的可维护性
? 软件维护的过程分析
? 基于构件复用的软件再工程
第一节 软件维护的基本概念
一、软件维护的定义
所谓软件维护 (Software Maintenance)就是在软
件已经交付使用之后，为了改正错误或满足用户新
的需要而修改软件的过程。软件在投入运行之前，
往往要经过严格的测试，但事实表明，测试阶段不
可能完全暴露软件潜在的错误。同时，用户的需求
是发展的，软件能充分满足用户需求是软件工程人
员追求的最高目标，也是软件生命力所在。
据, 美国程序员, 杂志 1995年 7月提供的统计资
料，全球大约 5/6的软件项目存在失败的部分。所以，
软件维护是任何软件生命周期必不可少的阶段，忽
视软件维护的软件工程是盲目的、危险的。
当今信息技术发展迅猛，计算机软硬件的升级频
率越来越快，网络等通讯技术突飞猛进，增加了软
件系统环境的复杂性，也使软件维护的方式产生了
根本性的变化。诸如电话提供解决方案、定期上门
维护和网上指导性维护等方式已经逐渐成为当今软
件维护的主要方式。
二、软件维护的分类
ANSI/IEEE在 20世纪 80年代从软件维护类型的角
度给出了软件维护的定义：, 软件维护是指软件成
品提供使用后，为了修改差错、改善功能和性能、
适应环境变化而进行的软件修正。, 这个对软件维
护的定义给出了软件维护的分类。
软件维护通常包括四类：
? 为了纠正在使用过程中暴露出来的错误而进行的
改正性维护；
? 为了适应外部环境的变化而进行的适应性维护；
? 为了改进原有的软件而进行的完善性维护；
? 以及为了提高可维护性和可靠性而进行的预防性
维护。
(一 )正确性维护 （ corrective maintenance）
正确性维护又称改正性维护，其主要任务是完成
软件潜在错误的改正。
（二）适应性维护 (adaptive maintenance)
适应性维护指为适应软件的外界环境变化而进行
的修改,它是由软件生存的环境变化引起的。任何系
统总是存在于一定的环境之中，环境与系统相辅相
成、相互作用。
对软件来说，环境变化源于以下几个方面：
(1)用户需求变化。 随着企业业务的不断变化
和发展，原系统业务流程图已不能准确描述现有企
业业务状况，因此，既存软件系统已经无法完全满
足用户的需求，原系统的数据变量定义和相关算法
要做适当修改。例如，国家税费调整、电话区号调
整及千年虫问题等等。
(2)软件环境的变化。 其一,硬件和操作系统
更新。软件运行的平台变化是软件适应性维护的主
要因素之一。由于硬件的更新换代，拓宽了软件的
运行空间，为软件运行效率的提高提供了基础，不
对软件进行适应性维护将对硬件资源造成巨大的浪
费。同时，高版本操作系统的推出，导致了大量应
用型软件与操作系统的冲突，必须对现有软件进行
适应性维护。 其二,系统运行环境的变化。如由主
机方式变为客户 /服务器方式，由客户 /服务器方式
变为 Web方式，这时的系统体系结构必须做相应的改
变。
(3)开发环境的升级 。 譬如现在常用的 VC++、
PowerBuilder等开发环境的升级换代如同操作系统
一样频繁发生，这样也会对系统提出适应性维护需
求。
（三）完善性维护 (perfective maintenance)
完善性维护指为扩充系统的功能和改善系统性能
而进行的修改，一般包括增加或修改功能，提高系
统的安全性、处理能力等任务。完善性维护通常需
要用户领域的介入，并且是一个带反馈的反复的功
能追加过程。从现实情况来看，现阶段软件维护的
主要形式是完善性维护，据有关统计数据表明：全
部维护活动的 50%到 70%是完善性维护。
完善性维护的的一般模型
(四 )预防性维护 (preventive maintenance)
预防性维护是为减少或避免以后可能需要的前三
类维护而对软件配臵进行的工作，通过再结构化、
再标准化等系统优化方法，提高系统的可维护性，
对文档进行维护，对数据进行重组。预防性维护有
较强的前瞻性，而且做好预防性维护工作能降低或
避免因为维护工作不充分、不及时导致软件系统瘫
痪带来的灾难性后果。
随着网络及通讯技术高速发展，我们对软件维护
又提出了新的要求。网络环境下软件的安全问题、
软件遭受黑客攻击及病毒破坏后的软件系统的恢复
工作也纳入软件维护的范畴。所以也可以这样说，
软件维护是指软件在交付使用后，为了使软件能正
常工作、修改潜在错误和满足用户新需求的一系列
对软件的修改及复原工作。
三,软件维护的内容
软件维护工作一般发生在客户使用软件产品的过
程中，由软件维护的分类可以看出，软件维护工作
一般由软件的用户和软件开发人员（或专职软件维
护人员）共同完成。其主要内容包括如下几点：
（一）程序维护
程序维护是指根据使用的要求，对程序进行全部
或部分修改。程序维护的最终目的是满足用户的需
求，对传统的软件工程而言，程序维护要修改用户
需求的概念模型和详细设计，并对源代码进行重新
修改，所以工作量较大且容易对原有功能产生破坏，
这是程序维护中不可忽视的一个问题。另外，根据
需要进行修改以后，必须书写修改设计报告。修改
设计报告必须和源代码同时维护，只有与程序完全
一致的修改设计报告才是真正有价值的文档。
（二）文件备份及修复
文件备份及修复属于数据维护的范畴，包括安装
与转换新的数据库出现异常或溢出时的补救和维护
工作。我们知道，对计算机系统而言，无论是硬件
系统或软件系统都有其脆弱性，所以如何提高其可
靠性一直是我们研究的重要课题。定期进行文件和
数据的备份和异常情况下的数据修复是提高软件可
靠性的一个有效手段。
（三）查杀病毒
计算机病毒对计算机软件的正常工作造成巨大
的威胁。一九八三年计算机病毒首次被确认，当时
人们并没有引起足够的重视。我国于一九八九年在
计算机界发现病毒。现在，全世界已发现数万种病
毒，并且还在高速度增加。由于计算机软件的脆弱
性与互联网的开放性，我们将与病毒长久共存。病
毒正朝着能更好的隐蔽自己并对抗反病毒手段的方
向发展，同时其破坏性越来越强,CIH病毒开创了对
硬件严重破坏的先河。对用户来说，要加强软件系
统的可靠性，查毒杀毒是软件维护阶段必不可少的
一个环节。降低病毒危害最有效的两个方法是：缩
短数据备份周期和加快杀毒软件的升级频率。
（四）硬件维护
硬件人员应加强设备的保养以及定期检修，并做
好检验记录和故障登记工作。虽然，硬件维护严格
意义上不是软件维护的范畴，但是没有硬件的强有
力的支持，软件就失去了运行的平台，硬件维护是
软件维护的基础工作。硬件维护包括评估现有硬件
设备、检测系统老化程度和运行状况、确定升级方
案和购买方案等等。
（ 五 ） 系统优化
系统优化是从系统全局出发，协调系统内部各组
成单元之间的连接关系，使整个系统按预定目标在
整体上达到最优。现在的软件不管操作系统还是应
用软件，随着其功能扩充与增强，变得越来越臃肿、
缓慢，我们还是只能忍受着，因为不管怎样，我们
必须要用它。鉴于此，我们要采用不同的优化方法，
针对不同的系统、不同的环节来采用不同的优化策
略。
四, 软件维护的特点
软件维护工作是一个变化的过程，这是由于软件
生存的内部环境和外部环境的变化引起的，任何企
业业务不可能较长时间的不变化，所以，软件系统
需要随着企业业务及管理模式的变化而进行适当调
整。当然，软件维护不同于计算机硬件或网络产品，
它有自己的维护特点。
（ 一 ） 软件维护耗时费力
软件维护是一项非常耗时、耗精力的工作。由于
现代企业的发展速度快，业务内容及业务流程不断
变化，用户不断追加功能需求。这样，软件维护的
周期大大缩短，软件开发人员必须投入大量的人力、
物力和财力去从事软件的维护工作。另外，软件用
户计算机应用的能力及熟练程度不同，造成用户对
软件的使用情况参差不齐，本来应该在软件培训阶
段完成的工作又要在维护阶段再一次提出来。
近期的调查报告发现软件工程 20%的工作量用在
开发上，而 80%用在维护上。但是，如果对于软件的
频繁修改、排错和功能追加，加上没有规范的管理
手段、有效的方法和技术，可能很快就会导致软件
结构的混乱和质量下降，最终结果是软件的夭折或
提前报废。
（ 二 ） 软件维护的代价昂贵
回顾软件业发展的历史，我们不难看出，软件维
护的费用所占软件工程总费用的比重节节攀升。从
1970年到 1990年的 20年间，比重成倍增加，达到 80%。
软件维护的代价是多方面的，除了经济方面的代价
外，软件维护还可能导致用户对软件开发人员的不
信任或不满；软件维护的改动，会破坏原有系统的
完整性，引入潜在错误，降低了软件质量的可靠性；
同时，当今软件开发人员的短缺是导致软件危机的
原因之一，软件维护工作花费了软件工程师的大量
时间和精力，使软件的生产率无法提高。
（ 三 ） 远程维护是现代软件维护的新途径
通讯和网络技术的发展为软件的维护提供了便捷
的方式。软件使用中会出现各种各样的问题，其中
有的问题可以通过电话,E-mail、在线交谈和视频
指导等方式加以解决。还有一部分问题，由于用户
对软件的开发环境不熟悉，维护人员对用户的使用
情况又不了解，所以维护人员必须看到问题发生的
实际情况才能解决。
如果软件维护人员到用户的单位去，这样既浪费
了时间又给用户添加了经济负担。 Symatec公司推出
的 Pcanywhere软件可以把用户的软件使用实际情况
再现于维护人员的计算机上，维护人员可以实现远
程维护。
Pcanywhere软件提供了文件传输, 远程控制和远
程网络需求的总体解决方案, 它具有如下功能：
1,Pc---Pc的远程控制
2,文件传输
3,运用远程网络连接使一台电脑成为网络中
的工作站
当然, 基于 WEB的多媒体软件维护系统也是现代
经常使用的一种软件维护方式之一 。
（ 四 ） 软件复用技术简化了软件维护
软件的复用以构件为基本单位，构件是可以明确
辨识的构成成分，软构件指在软件系统中具有一定
意义的相对独立的软件构成成分。特别是完善性维
护需要的正是可以被其它软件系统复用的、具有相
对独立功能的系统构成成分。基于构件的软件工程
的兴起、构件库的建立与维护越来越受到软件工程
师的重视，我们可以展望，在不远的将来，完善性
维护工作将更加简单化、产业化和自动化。
结构化维护与非结构化维护差异明显
对结构化维护而言, 起点是评价设计文档, 维护
步骤如下：
1,确定软件结构特点；
2,性能特点分析；
3,接口特点分析；
4,估量改动带来的影响；
5,计划实施途径；
6,修改设计并仔细复查；
7,编写相应的源代码；
8,进行回归测试；
９．交付使用。
然而, 非结构化维护的起点是评价程序代码,
其主要特征是难于评价软件结构, 全程数据结构,
系统接口和代码改动的后果 。 非结构化维护的步骤
如下：
1,分析用户需求；
２, 代码评价；
３, 评价反馈；
４, 重编程序；
５, 复查 （ 含重编程序反馈 ）
６, 交付使用 。
从两种维护的方式可以看出，非结构化维护以浪
费大量的精力为代价，原因是没有使用良好定义的
方法论来开发软件；相反，结构化维护能够使维护
工作井然有序，减少时间和精力的浪费，并且提高
软件维护的质量。
第二节 软件的可维护性
一,软件的可维护性
软件的可维护性是指软件能够被理解、改正、适
应和完善，以适应新的环境的难易程度。可维护性
的好坏是衡量一个软件工程成功与否的重要参数，
而且在软件开发的每一个阶段可维护性都是一个不
容忽视的问题。事实表明，目前现有的很多软件维
护工作开展困难甚至无法进行，原因是多方面的，
但有一点是共性，原有软件的可维护性较差。软件
可维护性研究的主要目的就是提高软件维护的可能
性，降低维护的花费，并把软件维护人员从繁琐的
维护工作中真正解放出来。
二、软件维护中问题
与软件维护有关的绝大多数问题的根源在于计划
阶段和开发阶段的工作有缺点,可以这样说，软件的
开发阶段潜在的错误和设计、规划的不合理是软件
维护阶段问题出现的根本原因。实践表明，绝大多
数的软件工程的软件维护阶段均会不同程度的出现
如下典型问题：
? 程序的源代码或算法可读性差，加大了软件维护
的难度。
? 文档丢失或文档不全。
? 软件的开发人员和软件维护人员分离，软件维护
的逆向工程花费软件维护人员的大量时间和精力。
? 软件本身可修改性差，无法二次开发。
? 开发方和出资方对软件维护的认识不足，资金追
加不够，软件维护工作无法深入。
? 软件维护工作繁琐，时间长，影响软件的正常使
用，容易导致用户对软件维护人员和软件系统的不
信任。
软件开发人员在软件开发过程中应该力求避免软
件维护阶段出现的问题。软件开发的工程化、软件
管理的科学化有助于解决与软件维护有关的若干问
题，所以，增强软件的可维护性是软件工程人员在
软件开发全周期必须时刻考虑的一个重要问题。
三、软件可维护性的决定性因素
软件生命周期每个阶段的工作都和软件可维护
性有密切的关系。良好的设计、完善的文档资料以
及一系列严格的复审和测试，使得一旦发现错误比
较容易诊断和纠正。因此，在软件周期的每个阶段
都必须充分考虑可维护性问题，并且为软件维护作
好准备。从软件自身的角度看，软件的可理解性、
可测试性、可修改性和可移植性是决定软件可维护
性的基本因素。
（一）文档的健全性
文档是影响软件可维护性的最重要因素，有时甚
至比可执行代码更为重要。文档可分为用户文档和
系统文档两大类。不管是哪一类文档都必须和源代
码同时维护，只有与程序完全一致的文档才是真正
有价值的文档。
(二 ) 可理解性
可理解性表现为外来读者理解软件的结构、接
口、功能和内部过程的难易程度。我们知道，现在
算法描述的工具和编程语言种类繁多，短时间内不
可能实现完全统一，所以模块化、详细的设计文档、
结构化设计、源代码的内部文档等都是增强软件可
读性和可理解性的有效方法。
（三）可测试性
可测试性是对软件正确性论证的容易程度。软
件工程中，软件修改和测试的难易程度主要取决于
软件容易理解的程度。
（四）可修改性
可修改性是指软件容易修改的程度，这里的修
改主要针对源代码或有关文档。软件的可修改性和
软件设计原则直接有关。可修改性好的软件在维护
时出现连带错误的概率相对较小。
（五）可移植性
随着面向对象的软件工程和基于构件的软件工程
技术的发展，软件的可移植性也成为衡量软件可维
护性的一个重要方面。可移植性指软件的部分程序
和某些模块转移到另一个计算机环境中去并能发挥
功能的可能性。可移植性强的软件不依赖于具体的
计算机环境，可以在不同的计算机和操作系统中正
常工作。
影响软件可维护性的几个因素是紧密相关的。没
有健全文档的软件维护几乎无法进行；维护人员在
正确理解一个程序之前根本不可能修改它；如果不
能进行完善的诊断和测试，则表面正确的修改可能
引起其他故障；可移植性强的程序往往可以进行单
独测试，也便于软件整体的修改维护。
因此，在软件开发的各个时期，我们应该把软件
的可维护性作为一个关键目标。只有这样才能保证
软件在较长的时间内能正常运行，即使有维护需求，
也能在较短时间内实现软件的维护，从而保证软件
有较好的可用性。
四、软件开发各阶段的可维护性要求
软件的维护是软件工程的最后一个阶段，指在软
件交付使用之后为保证软件能正常运行所进行的一
系列后期工作。但是，软件的可维护性贯穿软件开
发的各个阶段，没有各阶段可维护性保证，交付使
用的软件根本不可能实现维护。在软件开发的各阶
段应注意如下方面：
（一）需求分析分阶段：
对用户潜在的需求进行分析并留有实现的空间；
对将来可能改进的部分和可能会修改的部分加以注
意并指明；应该考虑软件的可移植性问题，软件的
复用可以增加软件的可维护性和降低软件维护工作
量；考虑可能实现软件维护的系统体系结构。
（二）设计阶段：
在设计阶段，代码冗余设计、编写健全的文档等
都与可维护性相关；应该从容易修改、模块化和功
能独立的目标出发；设计中应该对将来可能修改的
部分预先做准备。
（三）编码阶段：
编码阶段编码风格和内部说明文档是影响可维护
性的两个重要因素；不同的程序设计语言编写的程
序可维护性不同，一般情况下，高级语言的程序比
低级语言程序易于维护。同样是高级语言，各自的
可理解性也不同，目前看来，非过程化语言和面向
对象的语言较容易维护
（四）测试阶段：
软件测试实现预防性维护，检查所有的软件配臵
是否完整和可理解。
（五）维护阶段：
在完成每次维护工作之后，要修改源程序、设计
文档和用户手册。单纯的源代码修改会给以后的软
件维护带来障碍，产生严重的后果。
五、软件文档对软件可维护性的意义
良好的可维护性可以更快、更好地解决软件技术
问题；提高软件运行的性能和可靠性；为了从耗时
费力的软件维护问题中解放出来，降低用户软件运
行成本，减少混乱或瘫痪的时间，我们有必要进一
步研究以提高软件的可维护性。然而，软件文档对
软件的维护具有举足轻重的作用，软件文档是软件
维护的入口。
（一）软件文档的定义
软件文档是对软件总目标软件各组成部分之间的
关系、软件设计的策略和软件运行过程的历史数据
的说明和补充。软件本身不属于软件文档范畴，但
是文档和软件的源代码同样重要，缺一不可，相辅
相成。
（二）软件文档的内容要求：
系统使用说明书
系统安装和管理说明
系统需求和设计说明
系统的实现和测试说明
（三）软件文档的分类：
（ 1） 用户文档的内容：
功能描述,说明系统功能
安装文档,说明如何安装系统以及硬件配臵
需求。
使用手册,简要说明如何使用系统
参考手册,描述用户可以使用的所有系统设
施以及它们的使用方法。解释系统可能产生的各种
出错信息的含义。
操作员指南,说明操作员应该如何处理使用
中出现的各种情况。
（２）系统文档的内容：
系统文档是指从问题定义、需求说明到验收测试
计划等一系列和系统有关的文档。
软件维护费用在软件产品的开发费用中占了很大
一部分，应该说是最难的工作，开发人员最不愿意
作的工作，特别是在没有文档的情况下。要想提高
维护效率，首先开发过程中各种文档一定要齐备、
同时要保持与代码的同步，此外代码书 写过程中遵
循一定的规则（命名、注释等）。有了这两部分，
维护工作就不会无 处下手了。
第三节 软件维护的过程分析
一、软件维护的管理体系
维护工作中最常见的问题是错误扩散，主要包括
纠错性错误扩散与完善性错误扩散。因此，软件维
护需要建立一套完整的、科学的管理体系，即维护
管理体系。
对于产品的维护不能随便进行，要求建立申请 —
— 判断 —— 实施 —— 检查的过程，也就是任何维护
工作都要向有关部门申请，相关部门判断决定是否
实施及实施优先级，维护完成后还需要检查确认，
维护工作都要有记录。
在纠错过程中，往往纠正了这里的错误又引发了
其它地方发生错误，特 别是全局性的函数、变量、
过程、结构体的修改一定要慎重，此外各种接口的
修改也要慎重，千万不要引发其他的错误。完善性
维护增加了新的功能，也增加了 出错的可能，对此
一定要反复测试，最基本的要求就是不要破坏已有
的正常功能。维护活动完成后，一般要进行回归测
试，回归测试完成后才可交付用户使用。其具体过
程如下图：
软件维护管理体系
然而，如何实现新旧系统的转换呢？到底是直接
取代用户现在使用的老系统，还是新旧两套一起并
行运行呢？如果系统不是很重要，则可以马上取代
旧系统，应用修改过的新版本；如果对用户利益重
大则最好新旧一起用，互相参照监督，防止新版本
出现了老版本没有的问题，直到用户确认了新系统。
维护版本交付前，涉及软件的数据库等相关资源都
要备份，保证安全。
二, 软件的维护过程
（ 一 ） 建立维护组织
软件维护组织不是一个正式的常设组织，往往是
根据维护要求的提出而临时成立，它是一个为实现
软件维护而成立的人员团体。软件维护组织通常由
用户、技术员、维护管理员、高级系统管理员和局
部系统管理员组成，如下图所示：
软 件 维 护 组 织
原 软 件 系 统 +维 护 需 求
用 户 技 术 人 员 维 护 管 理 员 各 级 系 统 管 理 员
维 护 后 的 软 件 系 统
（二）编写维护报告
首先，我们要获得用户提出的维护需求，其方法
可以让用户填写用户维护申请表。维护需求有四类，
不同的维护需求表述的方式不同。对适应性和完善
性的维护需求，用户应该给出尽可能简洁的、准确
的需求描述。改正性维护往往是由于遇到软件运行
的错误，则用户必须详尽的描述错误发生的原因、
导致的相关后果，以及错误发生时软件运行的环境。
软件维护报告申请表设计如下图所示：
软 件 维 护 申 请 表
申 请 表 编 号, 申 请 日 期, 年 月 日
项 目 编 号 项 目 名 称
维
护
类
别
软
件
维
护
硬
件
维
护
改 正 性
完 善 性
适 应 性
预 防 性
系 统 设 备
外 围 设 备
问 题 说 明,
维 修 要 求,
维 修 优 先 级
申 请 人
维 护 方 式 远 程 /现 场
申 请 评 价 结 论,
评 价 负 责 人, 评 价 时 间,
软 件 维 护 申 请 表
根据用户给出的维护需求描述（表格或说明书），
软件组织要给出针对用户提出的维护需求的软件修
改报告，软件修改报告的内容比软件维护申请报告
的批复要详细。软件维修报告要求给出维护工作量
需求、维护要求的性质和与修改有关的数据。软件
修改报告交系统变化授权人审查后生效，软件组织
可以进行下一步详细的软件修改计划的制定和软件
修改的实施。
（三）进行软件修改
软件的维护是对正在使用的软件进行修改，它对
软件系统的正常使用造成影响，所以在软件修改实
施前必须提交申请报告。获准的对软件的修改才是
合法的，软件修改的主要内容和步骤如下：
(1)由系统管理员提出软件修改请求报告；
(2)由有关领导审批请求报告；
(3)源程序清单存档；
(4)手续完备后，实施软件的修改；
(5)软件修改后形成新的文档资料；
(6)发出软件修改和使用变更通知；
(7)进行软件修改后的试运行；
(8)根据运行情况作总结调整并修改文档资料；
(9)发出软件修改后，正式运行通知；
(10)软件做新的备份，并同定稿的文档资料一起
存档，这里的文档主要应包括以下内容：
维护的审批人、提请人、维护人的姓名、维护时
间、修改原因、修改的内容、修改后的现状。
（四）保存维护记录
为了能正确的计算软件维护的代价，评估维护技
术的有效性，我们要求完整的保存维护记录。维护
记录作为重要的文档为再次软件维护增强了可维护
性。维护记录的保存到底选取哪些数据呢？
Swanson提出了十八点内容：
1,程序标识；
2,源语句数；
3,机器指令条数；
4,使用的程序设计语言；
5,程序安装的日期；
6,安装程序后运行的次数；
7,安装程序后失效的次数；
8,程序变动的层次和标识；
9,因为程序变动而增加的源语句数；
10,因为程序变动而删除的源语句数；
11,每个改动耗费的人时数；
12,程序改动的日期；
13,软件工程师的名字；
14,维护要求表的识别；
15,维护类型；
16,维护开始和完成的日期；
17,累计用于维护的人时数；
18,与完成的维护相联系的纯效益。
以上 18条是保存维护记录的主要内容，可以针对
具体的维护状况适当增减记录的数据。总之，维护
记录的保存是为了健全文档，便于维护代价的计算、
维护技术的评估和增强软件的可维护性。
（五）评价维护结果
这是软件维护的最后一个阶段，其主要目的是对
维护的结果进行评价。维护结果的评价建立在相关
数据的基础之上，所以，维护的档案记录要做好。
根据档案记录的数据可以对维护工作做定量的计算
和评估。软件维护的评估可根据保存的维护记录从
七个方面进行，如下图所示：
软件维护定量评价方式
二, 软件维护引起的系统价值变化
计算机系统的组成分两大类，一是硬件系统，另
一个是软件系统。软件系统由系统软件和应用型软
件组成。软件维护对硬件的价值不发生影响，但是，
随着硬件技术的飞速发展和硬件设备生产的规模化，
硬件的更新加快而且价格的下降趋势迅速。
再者，操作系统平台的升级换代周期越来越短，
换代比例越来越高。半个世纪以来，大部分软件资
产并没能像硬件那样频繁地经历彻底的更新换代，
为了适应硬件的飞速换代，环境适应性维护周期也
越来越短，范围越来越大，加之用户的需求变化，
完善性维护的频率越来越快。软件维护的人、财、
物的投入必影响计算机系统的价格构成。从软件的
价值随着生存期而递增的特点来看，这并不违背市
场经济的价值规律。随着维护的深入，软件价值总
体呈递增趋势。软件维护对系统价值的构成的影响
情况如下图所示：
20多年前曾有人预言：软件进入维护期的比例将
随软件递增率一起增长，进入 21世纪后将有 80%的软
件人员从事维护性开发。由此可见，软件财富的绝
大部分是由软件维护阶段创造的，那么应该重视软
件维护，提高软件运行的可靠性，实现软件维护的
真正目标。
价值
系统生存周期
硬
件
价
值
软
件
价
值
硬
件
价
值
原
软
件
价
值
追
加
价
值
A
硬
件
价
值
原
软
件
价
值
追
加
价
值
A
追
加
价
值
B
原有软硬件价值比 A 次软件维护后价值比 B 次软件维护后价值比
软件维护对系统价值比的影响
第四节 基于构件复用的软件再工程
几十年来，硬件发展速度和更新换代的周期呈指
数型递增，而软件生产率表现为螺旋形发展，总也
追不上硬件。同时，社会对软件的需求飞速增长，
软件的开发能力不能满足社会需求的矛盾越来越突
出。因此，以软件复用（ Software Reuse）和软件
构件 (Software component)为核心的软件再工程方
法应运而生。
软件再工程（ Software Re-engineering）是指
对既存对象系统进行调查，并将其重构为新形式代
码的开发过程。最大限度地重用既存系统的各种资
源是再工程最重要的特点之一。显然，软件再工程
的关键技术是软件复用，软件构件是再工程的核心
与基础，也是软件复用的基本单位。我们认为，软
件再工程是未来一段时间软件工程的主流，它是解
决软件维护的有效手段，也是软件生产率提高的最
佳方式之一。
一, 软件再工程的起源
软件产品在其有限的生命周期后将会失去其原有
的功能与市场，虽然不同于日常生活中的普通商品
给环境带来巨大的污染，但是我们认为，只有可以
经过加工再利用的产品才能称为, 绿色的环保的产
品, 。现阶段，一面是人们日夜增长的软件需求，
一面是软件的开发能力相对不足，大量的既存软件
系统被弃之不用，带给人们的是巨大的资源浪费。
与其它的商品不同，越是庞大的、历史悠久的软
件系统越是宝贵的无形遗产。对既存软件系统的浪
费就是对宝贵遗产的损害，有人说，继承过去是软
件的立身之本，身后的历史越长，前面的路就越宽。
如果我们能轻松的重用过去，就能使软件工程产生
一次巨大的飞跃。
二, 软件再工程的定义
软件危机导致了软件再工程的产生和发展。软件
再工程的主要任务是优化软件体系结构，增强软件
的可维护性和可移植性，提高软件产品的生产效率
和产品质量。 Linda H.Rosenberg博士这样定义了软
件再工程：, 软件再工程是为了以新的形式重构已
经存在的软件系统而进行的检测、分析和更替，以
及随后的对新形式的实现, 。
三, 软件再工程的过程模型
软件再工程是一个过程，但不同于传统软件工程。
再工程经过抽象、改造、精化三个阶段，其过程可
以用下图描述：
基于构件的软件再工程的一般模型
现存系统
源代码
原概念世
界 改造
用户世界
用户需求
目标概念
世界
目标系统
源代码
抽象
构件库
精化整合
构件实例
搜索引擎
可见，软件再工程的过程源于源代码，以构建目
标系统源代码为终点。通常，我们把从现存系统的
代码分析、结构设计、实际需求分析到抽象出概念
世界的过程称为逆向过程，因为它与传统软件工程
的开发过程相反。在改造阶段，往往考虑到对系统
新功能的添加，需要用户领域的介入。
另外，我们把从目标概念世界到实际需求分析、
结构设计和目标源代码的生成过程称为正向过程。
所以说，软件再工程实际上属于软件生命周期中软
件维护的范畴，这种维护的主动性更强，它不是单
纯的改正性维护，相反，它是注重适应性、完善性
和预防性的维护。
四、软件构件
（一）构件的定义
相对系统而言，构件是可以明确辨识的构成成分，
软构件指在软件系统中具有一定意义的相对独立的
软件构成成分。软件再工程需要的正是可以被其它
软件系统复用的、具有相对独立功能的系统构成成
分。
（二）构件模型
一般情况下，构件由构件规约与构件实现两部分
构成。构件规约主要由构件模型来进行描述，给出
构件的本质特性。目前国内外已经形成许多构件模
型，诸如３ C模型,CORBA模型和青鸟构件模型等等。
它们几乎都详尽地描述了构件的名称、功能、对外
接口和相关参数化属性，向构件复用者提供了关于
构件的大量信息。当然，有时候构件的内部结构对
于构件的有效复用也是必不可少的。构件实现由构
件的生产者完成，复用者可不去关心它的细节，对
复用者而言，关键是构件模型中的构件规约。
对大量的构件进行有效的、科学的管理和建模，
以期方便构件的存储、检索、推理，是成功复用构
件的保证。在此，我们着重于构件描述、构件分类
和构件库组织的讨论与研究，它们也是构件建模的
核心内容。
五、构件模型的描述与构件复用方法研究
从软件再工程的角度看，构件描述是对构件本质
的抽象描述，为构件的制作和复用提供依据；从构
件模型的角度看，诸如实现方式、实现体、关联构
件、大小和生产日期等等信息也是构件模型的具体
内容。在此，我们介绍几种构件模型的描述的方法：
（一）构件模型的特征向量法
对于任意构件 X的所有属性 {a1,a2,…,ai,…,an}
采用向量法描述：
〈 a1(x),a2(x),…,ai(x),…,an(x)〉 ；
ai及 ai(x)是属性 -值的对偶。在构件的相似性研
究中，可以把任意构件看作 n维空间中的一个点。显
然，匹配任务转化为求解在 n维空间中与给定点距离
最近的点的问题。
给定的构件 X与构件库中的任意构件 Y的相似度可
以通过欧氏距离或麦考斯距离求得。针对事实上单
个属性对整体上的相似度有不同贡献，可以用带权
麦考斯距离求解目标构件和构件实例的相似度。很
显然，最大相似度的构件实体的获得需要全体构件
实例和理想构件的比较，这依赖于大量运算，算法
效率较低。
因此，我们提出一个改进的求解算法，在构件模
型采用特征向量描述的条件下，考虑便于实现构件
自学习和构件匹配算法，根据用户给出的理想构件，
把其属性分解为前臵属性和后续属性，从构件库中
获取与理想构件模型完全或部分匹配的构件实例。
如下图所示：
构 件 特 征 向 量 表 示 法 的 匹 配
res1
res2
pre1
pre2
pre3
pre4
pre5
res
res1
pre_x1
pre_x2
构 件 实 例
目 标 构 件
（ 2）构件模型的语义表示法
这种模型以语义为核心，给出构件的结构模型。
构件的结构模型约定了构件的组成，它是对构件实
体的抽象。对构件而言，它能提供一些功能，同时
其功能的实现以一定的所需构件为基础。为此，我
们必须给出构件的接口，用于描述通讯约束和构件
间通讯实现。其次，我们要给出对构件的功能和属
性的语义描述，语义描述的主要内容是构件的含义
和使用方法，它最终决定构件的复用价值。构件接
口的标准化实质上是构件语义形式化描述措施的一
个重要方面。
除此以外，还有前臵和后续条件定义操作、命名
服务中命名和命名上下文标准、目录和目录上下文
标准、事务服务描述符、部署描述符等，同时有命
名规则、目录和命名绑定规则、事务语义定义、资
源分布部署说明等。在不同标准中，它们都有自己
的形式化语义规定。基于语义的构件结构模型如下
图所示：
实 例 集
构 件 属 性 抽 象
构 件 功 能 抽 象
接 口 体 集 合 语 义 体 集 合 实 现 体 集 合
基 于 语 义 的 构 件 结 构 模 型
成功的软件构件复用需要对构件功能在语义上有
精确的定义，还需构件在特定使用环境中得到质量
和可靠性认证。没有这些保证，复用将是不可预见
的和冒险的。基于语义的构件模型表示如下：
构件,:＝ <规约，实现 > /*实现对装配透明 */
规约,:＝ <接口规约，结构规约 >
接口规约,:＝ <提供功能集，要求功能集 >
机构规约,:＝ <原子构件规约 >∣ <复合构件规约 >
构件的语义模型的建立促进了构件的描述和构件
组装的实施，为构件的检索、评价、剪裁和扩展奠
定了坚实的基础。
六、软件复用的前景
构件技术已经成为当今计算机领域的重要组成，
许多常用的开发工具提供了对不同构件模型的实现
支持，特别在一些分布式软件系统中，已经把软件
的构件化作为解决维护、扩展和升级的一种重要手
段；同时，伴随着用户对既存软件系统的需求递增，
在现在及将来的一段时间内，软件再工程进一步发
展还需要强大构件库支撑。
构件数据库的建立对构件复用具有重大意义，它
是用户或软件开发组织的一笔宝贵财富，构件可以
来源于历史上开发的软件模块，关键是在开发过程
中注意收集软件模块以及其完整的文档资料。另外，
其实构件可以迈向商业化道路，作为商品在市场上
流通，促进再工程的实施。但是，要使基于构件的
软件再工程成为现代软件工程的主流，构件的建模
还要在降低构件之间的相关性和提高构件内元素之
间的相关性等等方面作进一步研究，当然这本身也
是软件维护研究的课题。
