第八章- 维护

第八章-维护

了解软件维护的基本活动及主要内容。

1、软件维护的定义

软件的运行维护阶段是软件生命周期的最后一个阶段，所谓软件维护就是在软件已经交付使用之后,为了改正错误或满足新的需要而修改软件的过程。

软件维护的基本任务是保证软件在一个相当长的时期能够正常运行。

• 软件维护需要的工作量很大,平均说来,大型软件的维护成本高达开发成本的4倍左右。
• 目前国外许多软件开发组织把60%以上的人力用于维护已有的软件,而且随着软件数量增多和使用寿命延长,这个百分比还在持续上升。

2、软件维护的分类

（1）改正性维护

在任何大型程序的使用期间,用户必然会发现程序错误,并且把他们遇到的问题报告给维护人员。把诊断和改正错误的过程称为改正性维护。

（2）适应性维护

就是为了和变化了的环境适当地配合而进行的修改软件的活动,是既必要又经常的维护活动。

（3）完善性维护

在使用软件的过程中用户往往提出增加新功能或修改已有功能的建议,还可能提出一般性的改进意见,为此进行的维护称完善性维护。这项维护活动通常占软件维护工作的大部分。

（4）预防性维护

当为了改进未来的可维护性或可靠性,或为了给未来的改进奠定更好的基础而修改软件时,而进行的维护活动。

国外的统计数字表明，完善性维护占全部维护活动的50%～66%,改正性维护占17%～21%,适应性维护占18%～25%,其他维护活动只占4%左右。

上述4类维护活动都必须应用于整个软件配置,维护软件文档和维护软件的可执行代码是同样重要的。

3、软件维护的特点

（1）结构化维护与非结构化维护差别巨大

• 非结构化维护
  如果软件配置的惟一成分是程序代码,那么维护活动从评价程序开始,而且常常由于程序内部文档不足而使评价更困难,对于软件结构、性能和设计约束等经常会产生误解。
  非结构化维护需要付出很大代价,是没有使用良好定义的方法学开发出来的软件的必然结果。
• 结构化维护
  如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始。
  ①确定软件重要特点;估量要求的改动将带来的影响,计划实施途径；
  ②修改设计并且对所做的修改进行仔细复查;
  ③编写相应的源程序代码;进行回归测试;
  ④把修改后的软件再次交付使用。

（2）维护的代价高昂

维护费用只不过是软件维护的最明显的代价,其他一些现在还不明显的代价将来可能更为人们所关注。例如,可用的资源必须供维护任务使用，以致耽误甚至丧失了开发的良机，这是软件维护的一个无形的代价。

（3）维护的问题很多

在软件生命周期中没有严格而又科学的管理和规划，几乎必然会导致在最后阶段出现问题。

1. 理解别人写的程序通常非常困难,而且困难程度随着软件配置成分的减少而迅速增加。如果仅有程序代码没有说明文档,则会出现严重的问题。
2. 需要维护的软件往往没有合格的文档,或者文档资料显著不足。认识到软件必须有文档仅仅是第一步,容易理解的并且和程序代码完全一致的文档才真正有价值。
3. 当要求对软件进行维护时,不能指望由开发人员给我们仔细说明软件。
4. 绝大多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理的设计方法学,否则修改软件既困难又容易发生差错。
5. 软件维护不是一项吸引人的工作,形成这种观念很大程度上是因为维护工作经常遭受挫折。

4、软件维护过程

维护过程本质上是修改和压缩了的软件定义和开发过程,而且远在提出一项维护要求之前，与软件维护有关的工作应该开始了。

1. 建立一个维护组织。
2. 确定报告和评价的过程。
3. 规定事件序列。
4. 建立记录保管过程。
5. 评价维护活动。

（1）维护组织

每个维护要求都通过维护管理员转交给相应的系统管理员去评价。系统管理员对维护任务做出评价之后,由变化授权人决定应该进行的活动。

（2）维护报告

软件维护人员通常给用户提供空白的维护要求表——有时称为软件问题报告表，这个表格由要求一项维护活动的用户填写。要求如果遇到了一个错误，必须完整描述导致出现错误的环境。

维护要求表是一个外部产生的文件，它是计划维护活动的基础。

软件组织内部应该制定出一个软件修改报告,它给出下述信息:

• 满足维护要求表中提出的要求所需头的工作量;
• 维护要求的性质;
• 这项要求的优先次序;
• 与修改有关的事后数据。

在拟定进一步的维护计划之前,把软件修改报告提交给变化授权人审查批准。

（3）维护的事件流

首先应该确定要求进行的维护的类型。用户常常把一项要求看作是为了改正软件的错误(改正性维护)，而开发人员可能把同一项要求看作是适应性或完善性维护。

• 对一项改正性维护要求的处理，从估量错误的严重程度开始
• 如果是一个严重的错误，则在系统管理员的指导下分配人员，并且立即开始问题分析过程
• 如果错误并不严重，那么改正性的维护和其他要求软件开发资源的任务一起统筹安排
• 维护事件流中最后一个事件是复审，它再次检验软件配置的所有成分的有效性，并且保证事实上满足了维护要求表中的要求

适应性维护和完善性维护的要求沿着相同的事件流通路前进。应该确定每个维护要求的优先次序，并且安排要求的工作时间，就好像它是另一个开发任务一样。如果一项维护要求的优先次序非常高,可能立即开始维护工作。

不管维护类型如何,都需要进行同样的技术工作。这些工作包括修改软件设计、复查、必要的代码修改、单元测试和集成测试、验收测试和复审。不同类型的维护强调的重点不同，但基本途径是相同的。

（4）保存维护记录

对于软件生命周期的所有阶段而言,以前记录保存都是不充分的,软件维护则根本没有记录保存下来。由于这个原因,往往不能估价维护技术的有效性,不能确定一个产品程序的“优良”程度,而且很难确定维护的实际代价是什么。

保存维护记录遇到的第一个问题就是,哪些数据是值得记录的?

Swanson提出值得记录的数据：

• 程序标识
• 源语句数
• 机器指令条数
• 使用的设计语言
• 程序安装的日期
• 安装后程序运行的次数
• 安装后程序失效的次数
• 程序变动的层次和标识
• 程序变动增加的源语言数

（5）评价维护活动

如果已经保存维护记录了,则可对维护工作做一些定量度量。至少可从下述7个方面度量维护工作:

• 每次程序运行平均失效的次数;
• 用于每一类维护活动的总人时数;
• 平均每个程序、每种语言、每种维护类型所做的程序变动数;
• 维护过程中增加或删除一个源语句平均花费的人时数;
• 维护每种语言平均花费的人时数;
• 一张维护要求表的平均周转时间；
• 不同维护类型所占的百分比。

根据对维护工作定量度量的结果,可以做出关于开发技术、语言选择、维护工作量规划、资源分配及其他许多方面的决定,而且可以利用这样的数据去分析评价维护任务。