软件维护的概念

非结构化维护 软件配置的惟一成分是程序代码，没有文档。 维护活动从艰苦地评价程序代码开始，常常由于程序内部 文档不足而使评价更困难，对于软件结构、全程数据结构、 系统接口、性能和(或)设计约束等经常会产生误解。 因为没有测试方面的文档，所以不可能进行回归测试(即 指为了保证所做的修改没有在以前可以正常使用的软件功 能中引入错误而重复过去做过的测试)。 结构化维护 软件配置完整，维护工作从评价设计文档开始，确定软件 重要的结构特点、性能特点以及接口特点；估量要求的改 动将带来的影响，并且计划实施途径。然后首先修改设计 并且对所做的修改进行仔细复查。接下来编写相应的源程 序代码；使用在测试说明书中包含的信息进行回归测试； 最后，把修改后的软件再次交付使用。
在每次软件维护任务完成后，需要进行必要的情 况评审。这种评审是对以下问题的一个小结： （1）在当前情况下，设计、编码、测试中的哪 些方面能够改进？ （2）哪些维护资源是应该有而实际上却没有的？ （3）工作中的主要和次要的障碍是什么？ （4）要求的维护类型中有预防性维护吗？
8.3.4 维护记录
维护记录中的内容，包含了下述的项目表： （1）程序名称； （2）源程序语句条数； （3）机器代码指令条数； （4）使用的程序设计语言； （5）程序的安装日期； （6）程序安装后的运行次数； （ 7 ）与程序安装后运行次数有关的处理 故障的次数；
M＝p＋K×e(c – d) M：维护中消耗的总工作量； p：生产性工作量； K：经验常数； c：复杂程度； d：维护人员对软件的熟悉程度。 通过这个模型可以看出，如果使用了不好的软件 开发方法，参加维护的人员都不是原来开发的人员， 那么维护工作量（及成本）将按指数级增加。
8.2.3 维护的问题
（ 1 ）理解他人编写的程序一般都有一定的困难 性。 （ 2 ）软件配置的文档严重不足甚至没有，或者 没有合格的文档。 （ 3 ）当需要对软件进行维护时，由于软件人员 经常流动，维护阶段持续的时间又很长，所以一般不 能指望由原来的开发人员来完成或提供软件的解释。 （ 4 ）绝大多数软件在设计时没有考虑到将来的 修改问题。 （ 5）软件维护可以说是一项毫无吸引力的工作。 之所以形成这样一种观念，一方面是因为软件维护工 作量大，看不到什么“成果”，更主要的原因是因为 维护工作难度大，又经常遭受挫折。
第八章 软件维护
8.1 软件维护的概念
软件维护就是在软件已经交付使用之后， 为了改正错误或满足新的需要而修改软件 的过程。
wk.baidu.com
软件维护的种类
一般来说，要求进行维护的原因大致有以下几 种： （1）改正程序中的错误和缺陷。 （2）改进设计以适应新的软、硬件环境。 （3）增加新的应用范围。 综合以上几种要求进行维护的原因，我们可以 把软件维护分为以下四类：
8.3.5 维护评价
8.3.3 维护的工作流程
改正性 维护要求 确定类型 不严重 安排改正 完善性 或适应性 性维护 人员安排 评价错误 严重程度 严重 开始 问题分析
维护任务 评价 优先次序 低 错误改正目录 高 人员安排 开始分析 开发目录 复审 修改后的软件
通过后交付使用的软件
图8.2 维护阶段的事件流
无论是哪一种类型的维护，都要进行以下工作： （1）修改软件设计； （2）设计复审； （3）对源代码的必要修改； （4）单元测试； （5）集成测试，包括回归测试； （6）验收测试； （7）软件配置复审。
影响维护工作量的因素
1．系统的规模 2．系统的年龄 3．系统的结构 4．程序设计语言 5．文档的质量
8. 2 软件维护的特点
8.2.1
结构化维护与非结构化维护
维护要求
结 构 化 维 护
软件 配置 评价设计
代码
评价代码
计划途径 ？ 修改设计 重新编码 重新编码
非 结 构 化 维 护
复查
复查
交付使用
（8）程序修改的层次和名称； （9）由于程序修改而增加的源程序语句条数； （10）由于程序修改而删除的源程序语句条数； （11）每项修改所付出的“人时”数； （12）程序修改的日期； （13）软件维护人员的姓名； （14）维护申请报告的名称； （15）维护类型； （16）维护开始时间和维护结束时间； （17）用于维护的累计“人时”数； （18）维护工作的净收益。
8.3 软件维护过程
8.3.1 维护组织
图8.1 维护组织
每个维护要求都通过维护管理员转交给相应的系统管理员 去评价。系统管理员是被指定去熟悉一小部分产品程序的技术 人员。系统管理员对维护任务做出评价之后，由变化授权人决 定应该进行的活动。图8.1描绘了上述组织方式。
8.3.2 维护报告
维护申请报告是由软件组织外部提交的文档， 它是计划维护活动的基础。软件组织内部应依此制 定相应的软件修改报告，这个报告包括以下内容： （ 1 ）为满足某个维护申请要求所需的工作量； （2）所需修改变动的性质； （3）申请修改的优先级； （4）与修改有关的事后数据。 软件修改报告应提交修改负责人进行审核批准， 以便进行下一步工作。
8.2.2 维护成本
无形的维护成本： （1）一些看起来是合理的改错或修改的 要求不能及时满足，使得用户不满意； （2）维护时产生的改动，可能会带来新 的潜伏的故障，从而降低了软件的整体质量； （3）当必须把软件开发人员抽调去进行 维护工作时，将在开发过程中造成混乱。
用于软件维护的工作量可以分为两部分：一部 分用于生产性活动，另一部分用于非生产性活动。 维护工作量的计算表达式：
(1)改正性维护 诊断和改正用户使用软件时所发现的软件错 误的过程。 (2)适应性维护 为了使软件和变化了的环境适当地配合而进 行的修改软件的活动。 (3)完善性维护 用户在使用软件的过程中，往往提出增加新 功能或改变某些已有功能的要求，还可能要求进一 步提高程序的性能。为了满足这类要求而修改软件 的活动，称为完善性维护。 (4)预防性维护 为了改进未来的可维护性或可靠性，或为了给 未来的改进奠定更好的基础而修改软件。 目前，完善性维护占全部维护活动的一多半。