软件工程导论第8章

《软件工程导论第8章》由会员分享，可在线阅读，更多相关《软件工程导论第8章（68页珍藏版）》请在金锄头文库上搜索。

1、第8章 维护,8.1 软件维护的定义 8.2 软件维护的特点 8.3 软件维护过程 8.4 软件的可维护性 8.5 预防性维护 8.6 软件再工程过程 8.7 小结 习题,在软件产品被开发出来并交付用户使用之后，就进入了软件的运行维护阶段。这个阶段是软件生命周期的最后一个阶段，其基本任务是保证软件在一个相当长的时期能够正常运行。 软件维护需要的工作量很大，平均说来，大型软件的维护成本高达开发成本的4倍左右。目前国外许多软件开发组织把60%以上的人力用于维护已有的软件，而且随着软件数量增多和使用寿命延长，这个百分比还在持续上升。将来维护工作甚至可能会束缚住软件开发组织的手脚，使他们没有余力开发新

2、的软件。 软件工程的目的是要提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。,所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。可以通过描述软件交付使用后可能进行的4项活动，具体地定义软件维护。 因为软件测试不可能暴露出一个大型软件系统中所有潜藏的错误，所以必然会有第一项维护活动：在任何大型程序的使用期间，用户必然会发现程序错误，并且把他们遇到的问题报告给维护人员。把诊断和改正错误的过程称为改正性维护。,8.1 软件维护的定义,计算机科学技术领域的各个方面都在迅速进步，大约每过36个月就有新一代的硬件宣告出现，经常推出新操作系统或旧系统的

3、修改版本，时常增加或修改外部设备和其他系统部件；另一方面，应用软件的使用寿命却很容易超过10年，远远长于最初开发这个软件时的运行环境的寿命。因此，适应性维护，也就是为了和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动。,当一个软件系统顺利地运行时，常常出现第三项维护活动：在使用软件的过程中用户往往提出增加新功能或修改已有功能的建议，还可能提出一般性的改进意见。为了满足这类要求，需要进行完善性维护。这项维护活动通常占软件维护工作的大部分。 当为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件时，出现了第四项维护活动。这项维护活动通常称为预防性维护，

4、目前这项维护活动相对比较少。,从上述关于软件维护的定义不难看出，软件维护绝不仅限于纠正使用中发现的错误，事实上在全部维护活动中一半以上是完善性维护。国外的统计数字表明，完善性维护占全部维护活动的50%66%，改正性维护占17%21%，适应性维护占18%25%，其他维护活动只占4%左右。 应该注意，上述4类维护活动都必须应用于整个软件配置，维护软件文档和维护软件的可执行代码是同样重要的。,1. 非结构化维护,8.2 软件维护的特点 8.2.1 结构化维护与非结构化维护差别巨大,如果软件配置的惟一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难，对于

5、软件结构、全程数据结构、系统接口、性能和(或)设计约束等经常会产生误解，而且对程序代码所做的改动的后果也是难于估量的：因为没有测试方面的文档，所以不可能进行回归测试(即指为了保证所做的修改没有在以前可以正常使用的软件功能中引入错误而重复过去做过的测试)。非结构化维护需要付出很大代价(浪费精力并且遭受挫折的打击)，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。,2. 结构化维护 如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特点以及接口特点；估量要求的改动将带来的影响，并且计划实施途径。然后首先修改设计并且对所做的修改进行仔细复查。接

6、下来编写相应的源程序代码；使用在测试说明书中包含的信息进行回归测试；最后，把修改后的软件再次交付使用。,刚才描述的事件构成结构化维护，它是在软件开发的早期应用软件工程方法学的结果。虽然有了软件的完整配置并不能保证维护中没有问题，但是确实能减少精力的浪费并且能提高维护的总体质量。,在过去的几十年中，软件维护的费用稳步上升。1970年用于维护已有软件的费用只占软件总预算的35%40%，1980年上升为40%60%，1990年上升为70%80%。 维护费用只不过是软件维护的最明显的代价，其他一些现在还不明显的代价将来可能更为人们所关注。因为可用的资源必须供维护任务使用，以致耽误甚至丧失了开发的良机，

7、这是软件维护的一个无形的代价。其他无形的代价还有：,8.2.2 维护的代价高昂,当看来合理的有关改错或修改的要求不能及时满足时将引起用户不满； 由于维护时的改动，在软件中引入了潜伏的错误，从而降低了软件的质量； 当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱。 软件维护的最后一个代价是生产率的大幅度下降，这种情况在维护旧程序时常常遇到。,用于维护工作的劳动可以分成生产性活动(例如，分析评价，修改设计和编写程序代码等)和非生产性活动(例如，理解程序代码的功能，解释数据结构、接口特点和性能限度等)。下述表达式给出维护工作量的一个模型：M=P+Kexp(c-d) 其中： M是维护用的总

8、工作量，P是生产性工作量，K是经验常数，c是复杂程度(非结构化设计和缺少文档都会增加软件的复杂程度)，d是维护人员对软件的熟悉程度。 上面的模型表明，如果软件的开发途径不好(即，没有使用软件工程方法学)，而且原来的开发人员不能参加维护工作，那么维护工作量和费用将指数地增加。,与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺点。在软件生命周期的头两个时期没有严格而又科学的管理和规划，几乎必然会导致在最后阶段出现问题。下面列出和软件维护有关的部分问题： （1） 理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。如果仅有程序代码没有说明文档，则会出现严重

9、的问题。,8.2.3 维护的问题很多,（2） 需要维护的软件往往没有合格的文档，或者文档资料显著不足。认识到软件必须有文档仅仅是第一步，容易理解的并且和程序代码完全一致的文档才真正有价值。 （3） 当要求对软件进行维护时，不能指望由开发人员给我们仔细说明软件。由于维护阶段持续的时间很长，因此，当需要解释软件时，往往原来写程序的人已经不在附近了。 （4） 绝大多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理的设计方法学，否则修改软件既困难又容易发生差错。,（5） 软件维护不是一项吸引人的工作。形成这种观念很大程度上是因为维护工作经常遭受挫折。 上述种种问题在现有的没采用软件工程思想开

10、发出来的软件中，都或多或少地存在着。不应该把一种科学的方法学看做万应灵药，但是，软件工程至少部分地解决了与维护有关的每一个问题。,维护过程本质上是修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。首先必须建立一个维护组织，随后必须确定报告和评价的过程，而且必须为每个维护要求规定一个标准化的事件序列。此外，还应该建立一个适用于维护活动的记录保管过程，并且规定复审标准。,8.3 软件维护过程,1. 维护组织 虽然通常并不需要建立正式的维护组织，但是，即使对于一个小的软件开发团体而言，非正式地委托责任也是绝对必要的。每个维护要求都通过维护管理员转交

11、给相应的系统管理员去评价。系统管理员是被指定去熟悉一小部分产品程序的技术人员。系统管理员对维护任务做出评价之后，由变化授权人决定应该进行的活动。图8.1描绘了上述组织方式。 在维护活动开始之前就明确维护责任是十分必要的，这样做可以大大减少维护过程中可能出现的混乱。,图8.1 维护组织,2. 维护报告 应该用标准化的格式表达所有软件维护要求。软件维护人员通常给用户提供空白的维护要求表有时称为软件问题报告表，这个表格由要求一项维护活动的用户填写。如果遇到了一个错误，那么必须完整描述导致出现错误的环境(包括输入数据、全部输出数据以及其他有关信息)。对于适应性或完善性的维护要求，应该提出一个简短的需求

12、说明书。如前所述，由维护管理员和系统管理员评价用户提交的维护要求表。,维护要求表是一个外部产生的文件，它是计划维护活动的基础。软件组织内部应该制定出一个软件修改报告，它给出下述信息： (1) 满足维护要求表中提出的要求所需要的工作量； (2) 维护要求的性质； (3) 这项要求的优先次序； (4) 与修改有关的事后数据。 在拟定进一步的维护计划之前，把软件修改报告提交给变化授权人审查批准。,3. 维护的事件流 图8.2描绘了由一项维护要求而引出的一串事件。首先应该确定要求进行的维护的类型。用户常常把一项要求看作是为了改正软件的错误(改正性维护)，而开发人员可能把同一项要求看作是适应性或完善性维

13、护。当存在不同意见时必须协商解决。,图8.2 维护阶段的事件流,从图8.2描绘的事件流看到，对一项改正性维护要求(图中“错误”通路)的处理，从估量错误的严重程度开始。如果是一个严重的错误(例如，一个关键性的系统不能正常运行)，则在系统管理员的指导下分派人员，并且立即开始问题分析过程。如果错误并不严重，那么改正性的维护和其他要求软件开发资源的任务一起统筹安排。 适应性维护和完善性维护的要求沿着相同的事件流通路前进。应该确定每个维护要求的优先次序，并且安排要求的工作时间，就好像它是另一个开发任务一样(从所有意图和目标来看，它都属于开发工作)。如果一项维护要求的优先次序非常高，可能立即开始维护工作。

14、,不管维护类型如何，都需要进行同样的技术工作。这些工作包括修改软件设计、复查、必要的代码修改、单元测试和集成测试(包括使用以前的测试方案的回归测试)、验收测试和复审。不同类型的维护强调的重点不同，但是基本途径是相同的。维护事件流中最后一个事件是复审，它再次检验软件配置的所有成分的有效性，并且保证事实上满足了维护要求表中的要求。 当然，也有并不完全符合上述事件流的维护要求。当发生恶性的软件问题时，就出现所谓的“救火”维护要求，这种情况需要立即把资源用来解决问题。如果对一个组织来说，“救火”是常见的过程，那么必须怀疑它的管理能力和技术能力。,在完成软件维护任务之后，进行处境复查常常是有好处的。一般

15、说来，这种复查试图回答下述问题： 在当前处境下设计、编码或测试的哪些方面能用不同方法进行? 哪些维护资源是应该有而事实上却没有的? 对于这项维护工作什么是主要的(以及次要的)障碍? 要求的维护类型中有预防性维护吗? 处境复查对将来维护工作的进行有重要影响，而且所提供的反馈信息对有效地管理软件组织十分重要。,4. 保存维护记录 对于软件生命周期的所有阶段而言，以前记录保存都是不充分的，而软件维护则根本没有记录保存下来。由于这个原因，往往不能估价维护技术的有效性，不能确定一个产品程序的“优良”程度，而且很难确定维护的实际代价是什么。,保存维护记录遇到的第一个问题就是，哪些数据是值得记录的?Swan

16、son提出了下述内容： (1)程序标识；(2)源语句数；(3)机器指令条数；(4)使用的程序设计语言；(5)程序安装的日期；(6)自从安装以来程序运行的次数；(7)自从安装以来程序失效的次数；(8)程序变动的层次和标识；(9)因程序变动而增加的源语句数； (10)因程序变动而删除的源语句数； (11)每个改动耗费的人时数； (12)程序改动的日期； (13)软件工程师的名字； (14)维护要求表的标识； (15)维护类型； (16)维护开始和完成的日期； (17)累计用于维护的人时数； (18)与完成的维护相联系的纯效益。,应该为每项维护工作都收集上述数据。可以利用这些数据构成一个维护数据库的基础，并且像下面介绍的那样对它们进行评价。 5. 评价维护活动 缺乏有效的数据就无法评价维护活动。如果已经开始保存维护记录了，则可以对维护工作做一些定量度量。至少可以从下述7个方面度量维护工作： (1) 每次程序运行平均失效的次数； (2) 用于每一类维护活动的总人时数； (3) 平均每个程序、每种语言、每种维护类型所做的程序变动数；,(4) 维护过程中增加或删除一个源语句平均花费的人时数； (5