第六章软件维护技术

《第六章软件维护技术》由会员分享，可在线阅读，更多相关《第六章软件维护技术（60页珍藏版）》请在金锄头文库上搜索。

1、软件工程软件维护马丽6.1 软件维护的内容及特点6.2 软件的可维护性6.3 维护任务的实施6.4 预防性维护6.5 软件再工程过程第六章 软件维护 学习内容：在软件的开发工作已完成并把软件产品交付给用户使用之后，就进入了软件维护阶段。这个阶段的工作目 标是保证软件在一个相当长的时期内能够正常运行，因 此对软件的维护就成为必不可少的了。软件维护需要的工作量非常大。平均说来，大型软件的维护成本高达开发成本的四倍左右。目前国外许多 软件开发组织把60%以上的人力用于维护已有的软件，而 且随着软件数量增多和使用寿命延长，这个百分比还在 持续上升。将来维护工作甚至可能会束缚住软件开发组 织的手脚，使他

2、们没有余力开发新的软件。6.1 软件维护的内容及特点6.1.1 软件维护的内容所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。我们可以通过描述软件交付使用后可能进行的下述四项活动，具体地定义软件维护。1. 改正性维护通常，在软件开发过程中所进行的测试都是不完全、不彻底的，软件中必然会有一些潜伏的错误被带到 运行阶段来。用户常常将把他们遇到的问题报告给软件维护人员，要求解决。我们把诊断和改正软件错误的过程称为改正性维护。例如，在软件交付用户使用之后，解决在开发时没有 测试所有可能的执行通路而带来的问题；解决程序中遗 漏对文件中最后一个记录的处理的错误等。2.

3、适应性维护计算机科学技术领域的各个方面都在迅速进步，大约每过36个月就有新一代的硬件宣告出现；另一方面，应用 软件的使用寿命却很容易超过十年，远远长于最初开发这 个软件时的运行环境的寿命。因此，适应性维护就是为了 和变化了的环境适当地配合而进行的修改软件的活动，是 既必要又经常的维护活动。例如，适应性维护可以是修改原在DOS操作系统中运行的程序，使之能在Windows操作系统中运行；修改两个程序 ，使它们能够使用相同的记录结构；修改程序，使它适用 于另外一种终端设备。3. 完善性维护在使用软件的过程中，用户往往提出增加新功能或改变某些已有功能的要求，还可能提出提高程序性能的要 求。为了满足这类

4、要求而修改软件的活动，称为完善性维 护。例如，在储蓄系统交付银行使用之后，增加扣除利息税的功能；缩短系统的响应时间，使之达到新的要求；改 变现有程序输出数据的格式，以方便用户；在正在运行的 软件中增加联机求助功能等，都是完善性维护。4. 预防性维护当为了提高未来的可维护性或可靠性，或为了给未来的改进工作奠定更好的基础而修改软件时，就出现了第四类维 护活动，这类维护活动称为预防性维护。通常，把预防性维 护定义为：“把今天的方法学应用于昨天的系统以满足明天 的需要”。也就是说，预防性维护就是采用先进的软件工程方法对需要维护的软件或软件中的某一部分，主动地进行重 新设计、编码和测试。在维护阶段的最初

5、一二年，改正性维护的工作量往往比 较大。随着在软件运行过程中错误发现率迅速降低并趋于稳 定，就进入了正常使用期间。但是，由于用户经常提出改造 软件的要求，适应性维护和完善性维护的工作量逐渐增加， 而且在这种维护过程中往往又会引入新的错误，从而进一步 加大了维护的工作量。从上述关于软件维护的定义不难看出，软件维护绝不仅 限于纠正使用中发现的错误，事实上在全部维护活动中一半 以上是完善性维护。国外的统计数字表明： 完善性维护占全部维护活动的50%66% 改正性维护占17%21%， 适应性维护占18%25%， 其他维护活动只占4%左右。软件维护策略针对上一小节所述的三种典型的维护活动，James M

6、artin等人提出了一些可以减少维护成本的策略。下面学习主要的软件维护策略。1. 降低改正性维护成本的策略显然，软件中包含的错误越少，改正性维护的成本 也就越低，但是，要生成100%可靠的软件通常成本太高 ，并不一定合算。然而通过使用先进技术仍然可以大大 提高软件的可靠性，从而减少改正性维护的需求。 2. 降低适应性维护成本的策略这类维护是必然要进行的，但是要采取适当的策略。（1）在进行配置管理时，把硬件、操作系统和其他相关的 环境因素的可能变化考虑在内，可以减少某些适应性维护的 工作量；（2）把与硬件、操作系统及其他外围设备有关的代码放到 特定的程序模块中，可以把因环境变化而必须修改的程序代

7、 码局限于某些特定的程序模块内；（3）使用内部程序列表、外部文件及例行处理程序包，可 以为维护时修改程序提供方便。3. 降低完善性维护成本的策略上述的减少前两类维护成本的策略，通常也能降低 完善性维护的成本。特别是数据库管理系统、程序自动 生成系统、软件开发环境、第四代语言和应用软件包， 可明显减少维护工作量。此外，在需求分析过程中准确地预测用户将来可能 提出的需求，并且在设计时为将来可能提出的需求预先 做准备，显然是降低完善性维护成本的有力措施。在实际开发软件之前，建立软件的原型并让用户试 用，以进一步完善他们对软件的功能需求，也能显著减 少软件交付使用之后的完善性维护需求。6.1.2 软件

8、维护的的特点图6.1描绘了面对一项维护要求时，不同的软件配置所 导致的不同工作流程。图6.1 结构化维护与 非结构化维护的对比非结构化维护结构化维护6.1.2.1 结构化维护与非结构化维护差别悬殊如果软件配置的惟一成分是程序代码，那么维护活动 从艰苦地评价程序代码开始，而且常常由于程序内部文档 不足而使评价更困难（诸如软件结构、全程数据结构、系 统接口、性能或设计约束等微妙的特点是难于搞清的，而 且常常误解了这一类特点）。最终对程序代码所做的改动 的后果是难于估量的。 因为没有测试方面的文档，所以不可能进行回归测试。 这就是非结构化维护，这种维护方式是没有使用良好定义 的方法学开发出来的软件的

9、必然结果-并正在为此而付出 代价（浪费精力和受挫折）。非结构化维护(上图右侧)如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特点以及接口特点；估量要求的改动将带来的影响，并且计划实 施途径。然后首先修改设计并且对所做的修改进行仔细复 查。接下来编写相应的源程序代码；使用在测试说明书中 包含的信息进行回归测试；最后，把修改后的软件再次交 付使用。上面描述的事件构成结构化维护，它是在软件开发的早期应用软件工程方法学的结果。（它确实能减少精力的 浪费并且能提高维护的总体质量。）6.1.2.2 维护的代价高昂在过去的几十年中，软件维护的费用稳步上升。1970

10、年用于维护 已有软件的费用只占软件总预算的35%40%，1980年上升为40%60%， 1990年上升为70%80%。维护费用只不过是软件维护的最明显的代价，其他一些现在还不明 显的代价将来可能更为人们所关注。因为可用的资源必须供维护任务使 用，以致耽误甚至丧失了开发新软件的良机，这是软件维护的一个无形 的代价。其他无形的代价还有： 当看来合理的有关改错或修改的要求不能及时满足时 将引起用户不满； 由于维护时的改动，在软件中引入了潜伏的故障，从 而降低了软件的质量； 当必须把软件工程师调去从事维护工作时，将在开发 过程中造成混乱。软件维护的最后一个代价是生产率的大幅度下降，这种情况在维护旧程序

11、时常常遇到。例如，据Gausler在1976 年的报道，美国空军的飞行控制软件每条指令的开发成本 是75美元，然而维护成本大约是每条指令4000美元，也就 是说，生产率下降了50倍以上。用于维护工作的劳动（活动）可以分成生产性活动用于维护工作的劳动（活动）可以分成生产性活动（例如，分析评价，修改设计和编写程序代码等）和非生产性和非生产性活动活动（例如，理解程序代码的功能，解释数据结构、接口 特点和性能限度等）。下述公式给出维护工作量的一个模型:其中： M是维护用的总工作量P是生产性工作量K是经验常数c是复杂程度（非结构化设计和缺少文档都会增加 软件的复杂程度）d是维护人员对软件的熟悉程度。上面

12、的模型表明，如果软件的开发途径不好（即，没 有使用软件工程方法学），而且原来的开发人员不能参加 维护工作，那么维护工作量（和费用）将指数地增加。MPKexp（cd）6.1.2.3 维护的困难性与软件维护有关的绝大多数困难，都可归因于软件定义和软件开发的方法有缺点。在软件生命周期的头两个时 期没有严格而又科学的管理和规划，几乎必然会导致在最 后阶段出现问题。下面列出和软件维护有关的部分问题： 读懂别人写的程序通常非常困难。而且困难程度随 着软件配置成分的减少而迅速增加。如果仅有程序代码没 有说明文档，则会出现严重的问题。 需要维护的软件往往没有合格一致的文档，或者文 档资料显著不足。认识到软件必

13、须有文档仅仅是第一步， 容易理解并且和程序代码完全一致的文档才真正有价值。 当要求对软件进行维护时，不能指望由开发人员给我 们仔细说明软件。由于维护阶段持续的时间很长，因此， 当需要解释软件时，往往原来写程序的人已不在现场了。 绝大多数软件在设计时没有考虑将来的修改。除非使 用强调模块独立原理的设计方法学，否则修改软件既困难 又容易发生差错。 软件维护不是一项吸引人的工作。形成这种观念很大 程度上是因为维护工作经常遭受挫折。上述种种困难存在于现有的没采用软件工程思想开发 出来的软件中。不应该把一种科学的方法学看做万应灵药 ，但是，软件工程至少部分地解决了与维护有关的每一个 问题。6.2 软件的

14、可维护性6.2.1 软件的可维护性-指软件能够被维护人员理解、改正、适应和完 善以适应新的环境的难易程度。 决定软件可维护性的因素维护就是在软件交付使用后进行的修改，修改之前必须理解修改的对象，修改之后应该进行必要的测试，以保 证所做的修改是正确的。如果是改正性维护，还必须预先 进行调试以确定错误。因此，影响软件可维护性的因素主 要有下述七个：1. 可理解性2. 可测试性3. 可修改性4. 可靠性5. 可移植性6. 可重用性7. 效率6.2.2 文档文档是影响软件可维护性的决定因素。由于长期使用的大型软件系统在使用过程中必然会经受多次修改，所以文档比程序代码更重要。软件系统的文档可以分为用户文

15、档和系统文档两类。 用户文档主要描述系统功能和使用方法，并不关心这 些功能是怎样实现的； 系统文档描述系统设计、实现和测试等各方面的内容 。总的说来，软件文档应该满足下述要求：（1）必须描述如何使用这个系统，没有这种描述即使是最 简单的系统也无法使用；（2）必须描述怎样安装和管理这个系统；（3）必须描述系统需求和设计；（4）必须描述系统的实现和测试，以便使系统成为可维护 的。6.2.3 提高软件可维护性的方法从以下五方面解决：1建立明确的软件质量标准2利用先进的软件技术和工具3建立明确的质量保证制度4选择可维护的程序设计语言5改进软件的文档。6.2.4 可维护性复审可维护性是所有软件都应该具备

16、的基本特点。在软件工 程过程的每一个阶段都应该考虑并努力提高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对 可维护性进行复审。6.3 软件维护实施过程首先必须建立一个维护组织，随后必须确定报告和评价的过程，而且必须为每个维护要求规定一个标准化的事件 序列。此外，还应该建立一个适用于维护活动的记录保管 过程，并且规定复审标准。6.3.1 维护组织虽然通常并不需要建立正式的维护组织，但是，即使对于一个小的软件开发团体而言，非正式地委托责任也是绝 对必要的。维护机构成员一般包括：配置管理员、维护控 制员、系统管理员、一般维护工作人员。每个维护要求都通过维护管理员转交给相应的系统管理员去评价，见下页图示。维护机构提示：在维护 活动开始之前就 明确维护责任是 十分必要的，这 样做可以大大减 少维护过程中可 能出现的混乱。系统管理员是被指定去熟悉一小部分产品程序的技术人员。 系统管理员对维护任务做出评价之后，由变化授权人决定应 该进行的活动。图6.2描绘了上述组