第八章软件维护

3
④ 软件维护工作是一项难出成果，大家都不愿意干的工作。
8.1.4 软件维护的代价
1.软件维护的工作量大 软件维护的费用在整个软件开发费用的 55%-70%，并且所占比例在逐年上升。而且维 护中还可能产生新的潜在错误。例如 1970 年维护费用约占软件开发费用的 40%，到 1990 年维护费用所占比例就超过了 70%。另外维护还包含了无形的资源占用，包括大量的使用 很多硬件、软件和软件工程师等资源。 在软件维护时，直接影响维护成本和工作量的因素很多，主要如下： （1）系统规模大小 系统规模大小直接影响维护工作量，系统规模越大，仅仅看懂理解就很困难，维护的 工作量就更多。系统规模主要由源代码行数、程序模块数、数据接口文件数、使用数据库 规模大小等因素衡量。 （2）程序设计语言 参与软件开发的人员都知道，解决相同的问题选择不同的程序设计语言，得到的程序 的规模可能不同，由此应选择功能强且适合解决问题的程序设计语言，这样可以使生成程 序的指令数更小。 （3）系统使用年限 使用年限长的老系统维护比新系统所需要的工作量更多。老系统因已经进行多次维 护，参与维护的人员也不断变化，因此这样的系统结构更乱，如果没有系统说明和设计文 档，维护就更加困难。 （4）软件开发新技术的应用 软件开发过程中，使用先进的分析和设计技术，以及程序设计技术，如：面向对象的技术、 构件技术、可视化程序设计技术等，可以减少维护工作量。 （5）设计过程中的技术 在具体对软件进行维护时，影响维护工作量的其他因素还有很多，例如设计过程中应 用的类型、数学模型、任务的难度、开关与标记、IF 嵌套深度、索引或下标数等。 2.软件维护工作量模型 维护活动分为生产性活动和非生产性活动。生产性活动包括分析评价、修改设计和编 写程序代码等。非生产性活动包括理解程序代码，解释数据结构，接口特点和设计约束等。 Belady 和 Lehman 提出软件维护工作模型：
软件维护的管理流程如图 8.5 所示：
5
用户
维护人员
修改过 的软件
更改要求
纠错性
维护 要求
完 美 性
或
严重
或
不严重
安排改正 性维护
将改正错误列入计划
低
将安排好的工 作量列入计划
评价优 先级 或
高 进行问 题分析
８.4 软件维护的工作流程图
进行问
题分析 人 员 安 排
系统管理员
维护人员
配置管理员
软件系统
图8.3 软件维护组织
维护管理员可以是某个人，也可以是一个包括管理人员、高级技术人员等在内的小组。 维护管理员将提交的维护申请交给系统管理员进行评价，然后由修改批准人员决定如何修 改，交维护人员在系统管理人员的指导下对软件进行修改。在修改过程中，配置管理员对 软件配置进行审查。
8.1.2 软件维护的类型
根据以上目的可以把维护活动可以归纳为完善性维护、适应性维护、纠错性维护和预 防性维护四类。
1.完善性维护（Perfective Maintenance）在软件漫长的使用过程中，为了满足用户使 用过程中对软件提出的新的功能与性能要求，需要对原来的软件的功能进行修改或扩充， 这种扩充软件功能、增强软件性能、提高软件运行效率和可维护性而进行的维护活动称为 完善性维护。此维护活动工作量较大占整个维护工作的 50%。例如：对人事管理程序，在 使用中要不断修改人事管理程序，使其增加或删除新的项目，满足新需求；原来软件的查 询响应速度较慢，要提高软件的响应速度；改变原来软件的用户界面或增加联机帮助信息； 为软件的运行增加监控设施等。
8.2.1 维护组织一般维护需要保持一个正式的组织机构，但委派一个
除了较大的软件公司外，通常的在软件维护工作方面，并不保持一个正式的组织。在 软件开发部门，确立一个非正式的维护组织即非正式的维护管理员来负责维护工作却是绝 对必要的。图 8.3 给出了一种典型的维护组织方式。
维护申请
维护管理员
修改批准人员
理解分析程序
安排计划 修改程序
维护实施
测试程序
复审
交付使用 的软件
维护修改建议
进行测试
分析修改建议
提交管理部门审批
N 是否合理
Y
提交管理部门审查
N 是否批准
Y
更新主文档
M=P+K*EXP（C-D） 其中：M 表示维护总工作量，P 表示生产性活动工作量，K 表示经验常数，C 表示由非结 构化维护引起的程序复杂度，D 表示对维护软件熟悉程度的度量。上式可以发现，C 越大， D 越小，那么维护工作量就成指数的增加。C 增加主要因为软件采用非结构化设计，程序 复杂性高；D 减小表示维护人员不是原来的开发人员，不熟悉程序，理解程序花费太多时 间。
预防性维护4%
完善性 维护 50%
纠错性维 护25%
适应性 维护21%
图8.1 各类维护所占的比例
其余 29%
维护 71%
图8.2 维护工作比例
2
8.1.3 软件维护的特性
1.时间长、工作量大、成本高 软件的维护过程是软件生存期中最长，并且相当困难的阶段，软件维护的工作量占整 个软件生存期的７０％（如图 8.2 所示）以上，而且还在逐年增加。因此，如何减少软件 维护的工作量，降低软件维护的成本，就成为提高软件维护效率和质量的关键。 2.维护的副作用 通过维护可以延长软件的寿命使其创造更多的价值，但是，修改软件是危险的，每修 改一次，可能会产生新的潜在错误。因此，维护的副作用是指由于修改程序而导致新的错 误或者新增加一些不必要的活动。一般维护产生的副作用有如下三种。 （１）修改代码的副作用在修改源代码时，由于软件的内在结构等原因，任何一个小 的修改都可能引起的错误。因此在修改时必须特别小心。 （２）修改数据的副作用在修改数据结构时，有可能造成软件设计与数据结构不匹配， 因而导致软件出错。数据副作用就是修改软件信息结构导致的结果。修改数据副作用可以 通过详细的设计文档加以控制，此文档中描述了一种交叉作用，把数据元素、记录、文件 和其他结构联系起来。 （３）修改文档的副作用 对软件的数据流、软件结构、模块逻辑等进行修改时，必须对相关技术文档进行相应 修改。但修改文档过程会产生新的错误，导致文档与程序功能不匹配，缺省条件改变等错 误，产生文档的副作用。 为了控制因修改而引起的副作用，应该：按模块把修改分组；自顶向下的安排被修改 模块的顺序；每次修改一个模块。 3.软件维护的困难 由于软件维护工作通常并不由软件的设计和开发人员来完成，维护人员首先要对软件 各阶段的文档和代码进行分析、理解。因而出现了理解别人的程序困难、文档不齐等问题， 尤其是对大型、复杂系统的维护，更加困难和复杂，甚至是不可能的！ （1）结构化维护和非结构化维护 ①非结构化维护是只有源程序，缺乏必要的文档说明，难于确定数据结构、系统接口 等特性。维护工作令人生畏，事倍功半。 ②结构化维护是指软件开发过程是按照软件工程方法进行，开发各阶段文档齐全，软 件的维护过程，有一整套完整的方案、技术、审定过程。 可以看到，维护工作的难度及工作量的大小，明显的与前期的开发工作密切相关。 （2）维护的困难 软件维护的困难主要是由于软件需求分析和开发方法的缺陷造成的。这种困难主要有 如下几个方面： ① 读懂别人编的程序困难。 ② 文档的不一致性。 ③ 软件开发人员和软件维护人员在时间上的差异。
1
此项维护主要采用的策略可以使用功能强、使用方便的工具，采用原型化方法开发等。 2.适应性维护（Adaptive Maintenance）适应性维护是为了适应计算机的飞速发展， 使软件适应外部新的硬件和软件环境或者数据环境（数据库、数据格式、数据输入/输出 方式、数据存储介质）发生的变化，而进行修改软件的过程。适应性维护占整个维护工作 的 25%。例如：为现有的某个应用问题实现一个数据库管理系统；对某个指定代码进行修 改，如：从 3 个字符改为 4 个字符；缩短系统的应答时间，使其达到特定的要求；修改两 个程序，使它们可以使用相同的记录结构；修改程序，使其适用于另外的终端。 它主要的维护策略是对可能变化的因素进行配置管理，将因环境变化而必须修改的部 分局部化，即局限于某些程序模块等。 3.纠错性维护（Corrective Maintenance）软件测试不可能找出一个软件系统中所有 潜伏的错误，所以当软件在特定情况下运行时，这些潜伏的错误可能会暴露出来。对在测 试阶段未能发现的，在软件投入使用后才逐渐暴露出来的错误的测试、诊断、定位、纠错 以及验证、修改的回归测试过程，称为纠错性维护。纠错性维护占整个维护工作的 21%， 例如：修正原来程序中并未使开关复原的错误；解决开发时未能测试各种可能条件带来的 问题；解决原来程序中遗漏处理文件中最后一个记录的问题。 它的主要维护策略是开发过程中采用新技术，利用应用软件包，提高系统结构化程度， 进行周期性维护审查等。 4.预防性维护（Preventive Maintenance） 预防性维护是为了提高软件的可维护性和可靠性，采用先进的软件工程方法对需要维 护的软件或软件中的某一部分重新进行设计、编制和测试，为以后进一步维护和运行打好 基础。也就是软件开发组织选择在最近的将来可能变更的程序，做好变更它们的准备。由 于对于该类维护工作必须采用先进的软件工程方法，对需要修改的软件或部分进行设计、 编码和测试。对该类维护工作的必要性有争议，所以它在整个维护活动中占较小的比例约 占 4%。例如：预先选定多年留待使用的程序；当前正在成功地使用着的程序；可能在最 近的将来要做重大修改或增强的程序。 它的维护策略主要是常采用提前实现、软件重用等技术
8.2.2 维护工作的流程
图 8.4 描述了实施软件维护的工作流程，根据用户或维护人员的更改要求，进行维护 申请经过评审后，首先要确定维护的类型，还要分辨错误的严重程度或修改优先级的高低， 分别处理。
8.2.3 维护工作的组织管理
软件维护工作不仅是技术性的，它还需要大量的管理工作与之相配合，才能保证维护 工作的质量。管理部门应对提交的修改方案进行分析和审查，并对修改带来的影响作充分 的估计，对于不妥的修改予以撤销。需修改主文档时，管理部门更应仔细审查。