《第八章 维护课件》由会员分享，可在线阅读，更多相关《第八章 维护课件（40页珍藏版）》请在金锄头文库上搜索。
1、第八章 维 护,8.1 软件维护的定义,软件维护就是在软件已经交付使用之后，为改正错误或满足新的需要而修改软件的过程 软件交付后可能进行的四项活动： 改正性维护 在任何在型程序使用期间，用户必然会发现程序错误，并且把问题报告给维护人员 适应性维护 为了和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动 完善性维护 在使用软件的过程中用户往往提出增加新功能或修改已有功能的建议,预防性维护 为国改进未来的可维护或可靠性，或为了给未来的改进奠定更好的基础而修改软件时出现的,8.2 维护的特点,结构化维护与非结构化维护的对比 维护的代价 维护的问题,8.2.1 结构化维护与非结构
2、化维护的对比,图8.1描绘了作为维护要求的结果可能发生的事件流,如果软件开发包配置的唯一成分是程序代码,那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价困难 如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特点以及接口特点；估量要求的改动将带来的影响，并且计划实施途径,8.2.2 维护的代价,因为可用的资源必须供维护任务使用，以致耽误甚至丧失了开发的良机，这是软件维护的一个无形的代价。 其它无形的代价还有： 当看来合理的有关改错或修改要求不能及时满足时将引起用户不满 由于维护时的改动，在软件中引入了潜伏的故障，从而降低了软件的
3、质量 当必须把软件工程师调支从事维护工作时，将在开发过程中造成混乱 软件维护工作的最后一个代价是生产率的在幅度下降，这种情况在维护旧程序时常常遇到,8.2.3 维护的问题,与软件维护在关的绝在多数问题，都可归因于软件定义和软件开发的方法有缺点。 下面列出和软件维护有关的部分问题： 理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。如果仅有程序代码没有说明文档，则会出现严重的问题 需要维护的软件往往没有合格的文档，或者文档资料显著不足。认识到软件必须有文档仅仅是第一步，容易理解的并且和程序代码完全一致的文档才真正有价值 当要求对软件进行维护时，不能指望由开发人员给我们仔
4、细说明软件。由于维护阶段持续的时间很长，因此，当需要解释软件时，往往原来写程序的人已经不在附近了,绝在多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理的设计方法论，否则修改软件既困难又容易发生差错 软件维护不是一项吸引人的工作，形成这种观念很在程度上是因为维护工作经常遭受挫折,8.3 维护过程,维护组织 维护报告 维护的事件流 保存维护记录 评价维护活动,维护过程本质上是修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作就开始了。 首先必须建立一个维护组织，随后必须确定报告和评价过程，而且必须为每个维护要求规定一个标准化的事件序列。此外，还应
5、该建立一个适用于维护活动的记录保管过程，并且规定复审标准。,8.3.1 维护组织,虽然通常并不需要建立正式的维护组织，但是，即使对于一个小的软件开发团体而言，非正式地委托也是绝对必要的，每个维护要求都必须要求维护管理员转交给相应的系统管理员支评价。系统管理员是被指定支熟悉一小部分程序的技术人员。系统管理员对维护任务做出评价后，由变化授权人决定应该进行的活动。 图8.2描绘了上述组织方式,8.3 维护过程,软件维护人员通常给用户提供空白的维护要求表-有时称为软件问题报告表 维护要求表是一个外部产生的文件,它是计划维护活动的基础。软件组织内部应该制定出一个软件修改报告，它给出下述信息： 满足维护要
6、求表中提出的要求所需要的工作量 维护要求的性质 这项要求的优先次序 与修改有关的事后数据 在拟定进一步的维护计划之前，把软件修改报告提交给变化授权人审查批准,8.3.3 维护的事件流,图8.3描绘了由一项维护要求而引出的一串事件。首先应该确定要求进行的维护的类型。用户常常把一项要求看作是为了改正软件的错误（改正性维护），而开发人员可能把同一项要求看作是适应性或完善性维护。当存在不同意见时必须协商解决。,在完成软件维护任务之后，进行处境复查常常是有好处的。一般说来，这种复查试图回答一述问题： 在当前处境下设计、编码或测试的哪些方面能用不同方法进行 哪些维护资源是应该有而事实上却没有的 对于这项维
7、护工作什么是主要的（以及次要的）障碍 要求的维护类型中有预防性维护吗,8.3.4 保存维护记录,对于软件生命周期的所有阶段而言,以前记录保存都是不充分的,而软件维护则根本没有记录保存下来 值得记录的数据： 程序标识 源语句数 机器指令条数 使用的程序设计语言 程序安装的日期 自从安装以来程序运行的次数 自从安装以来程序失效的次数 程序变动的层次和标识,因程序变动而增加的源语句数 因程序变动而删除的源语句数 每个改动耗费的人时数 程序改动的日期 软件工程师的名字 维护要求表的标识 维护类型 维护开始和完成的日期 累计用于维护的人时数 与完成的维护相联系的纯效益,应该为每项维护工作都收集上述数据。
8、可以利用这些数据构成一个维护数据库的基础，并且像下一小节介绍的那样对它们进行评价,8.3.5 评价维护活动,从下述七个方面度量维护工作： 每次程序运行平均失效的次数 用于每一类维护活动的人时数 平均每个程序、每种语言、每种维护类型所做的程序变动数 维护过程中增加或删除一个源语句平均花费的人时数 维护每种语言平均花费的人时数 一张维护要求表的平均周转时间 不同维护类型所占的百分比,8.4 可维护性,决定软件可维护性的因素 文档 可维护性复审,8.4.1 决定软件可维护的因素,影响软件维护的主要因素有三个： 可理解性 软件可理解性表现为外来读者理解软件的结构、接口、功能和内部过程的难易程度。 可测
9、试性 诊断和测试的难易程度主要取决于软件容易理解的程度。良好的文档对诊断和测试是至关重要的 可修改性 软件容易修改的程度和本书第四章讲述的设计原理和规则直接相关。 上述三个因素是紧密相关的。维护人员在正确理解一个程序之前根本不可能修改它；如果不能进行完善的诊断和测试，则表面正确的修改可能引进其它故障 。,8.4.2 文档,文档是影响软件可维护性的决定因素。 软件系统的文档可以分为用户文档和系统文档 总的说来，软件文档应满足下述要求： 必须描述如何使用这个系统，没有这种描述既使是最简单的系统也无法使用 必须描述如何安装和管理这个系统 系统的需求和设计 系统的实现和测试，以便使系统成为可维护的,用
10、户文档 用户文档能使用户获得对系统的准确的初步的印象。 它至少包含下述五方面的内容： 功能描述 安装文档 使用手册 参考手册 操作员指南 系统文档 系统文档指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档,8.4.3 可维护性复审,可维护性是所有软件都应具有的基本特点 在需求分析阶段的复审过程中，应该对将来要改进的部分和可能会修改的部分加以注意并指明；应该讨论软件的可移植性问题，并且考虑可能会影响软件维护的系统界面 每个测试步骤都可以暗示在软件正式交付使用前，程序中可能需要做预防性维护的部分。在测试结束时进行最正式的可维护性复审，称为配置复审。它的目的是保证软件配置的所有成分
11、是完整的、一致的和可理解的，而且为了便于修改和管理已编目归档了 在完成了每项维护工作之后，都应该对软件维护本身进行仔细认真的复审 维护应该针对整个软件配置，不应该只修改源程序代码 每当对数据、软件结构、模块过程或任何其他有关的软,件特点做了改动时，必须立即修改相应的文档 用户通常根据描述软件特点和使用方法的用户文档来使用、评价软件 如果在软件再次交付使用之前，对软件配置进行严格的复审，则可大大减少文档的问题 为了从根本上提高软件的可维护性，人们试图通过直接维护软件规格说明来维护软件（参见本书第六章第6.2.3节），同时也在大力发展软件重用技术,小 结,维护是软件生命周期的最后一个阶段，也是持续时间最长代价最大的一个阶段。软件工程学的主要目的就是提高软件的可维护性，降低维护的代价 软件维护通常包括四类活动：改正性维护、适应性维护、完善性维护和预防性维护 软件的可理解性、可测试性和可修改性是决定软件可维护性的基本因素 文档是影响软件可维护性的决定性因素。因此，它甚至比程序代码更重要。文档可分为用户文档和系统文档。不管是哪一类文档都要和程序代码同时维护,只有和程序代码完全一致的文档才是正直有价值的文档 软件重用技术是能从根本上提高软件可维护性的重要技术，而本书第九章至第十二章讲述的面向对象的软件技术是最成功的软件重用技术,
