软件工程第八章维护

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

1、第八章 维护,在软件产品被开发出来并交付用户使用之后，就进入了软件的运行维护阶段。这个阶段是软件生命周期的最后一个阶段，其基本任务是保证软件在一个相当长的时期能够正常运行。软件维护是指软件系统交付使用以后，为了改正错误或满足新的需求而修改软件的过程。,维护阶段是软件生存期中最长的一个阶段，工作量很大，平均说来，大型软件的维护成本是开发成本的4倍左右。目前国外许多软件开发组织把60%以上的人力用于维护已有的软件，而且随着软件数量增多和使用寿命延长，这个百分比还在持续上升。将来维护工作甚至可能会束缚住软件开发组织的手脚，使他们没有余力开发新的软件。因此，应充分认识到维护工作的重要性和迫切性，提高软

2、件的可维护性，减少维护的工作量和费用，延长已开发软件的生命期，以发挥其应有的效益。,软件工程的目的是要提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。,对软件进行维护的目的是：为了纠正软件开发过程未发现的错误，增强、改进和完善软件的功能和性能，以适应软件的发展，延长软件的寿命。,8.1软件维护的定义,所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。 维护的类型有四种：改正性维护适应性维护完善性维护预防性维护,改正性维护,在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。 这些隐藏下来的错误在某些特定的

3、使用环境下就会暴露出来。 为了识别和纠正软件错误、改正软件性能上的缺陷，而进行诊断和改正错误的过程就叫做改正性维护。,适应性维护,在使用过程中，外部环境（新的硬、软件配置）数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质） 可能发生变化。 为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。,完善性维护,在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。 为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。 这种情况下进行的维护活动叫做完善性维护。,实践表明，在几种维护活动中，完善性维护所占的比重最大。即大部分维护

4、工作是改变和加强软件，而不是纠错。 完善性维护不一定是救火式的紧急维修，而可以是有计划、有预谋的一种再开发活动。 事实证明，来自用户要求扩充、加强软件功能、性能的维护活动约占整个维护工作的50。,预防性维护,预防性维护是为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件。,在整个软件维护阶段所花费的全部工作量中，完善性维护占了几乎一半的工作量。 国外的统计数字表明，完善性维护占全部维护活动的50%66%，改正性维护占17%21%，适应性维护占18%25%，其他维护活动只占4%左右。,维护在软件生 三类维护占 存期所占比例 总维护比例,影响维护工作量的因素,在软件的维护过

5、程中，需要花费大量的工作量，从而直接影响了软件维护的成本。 应当考虑有哪些因素影响软件维护的工作量，相应应该采取什么维护策略，才能有效地维护软件并控制维护的成本。,系统大小：系统越大，理解掌握起来越困难。系统越大，所执行功能越复杂。因而需要更多的维护工作量。 程序设计语言：使用强功能的程序设计语言可以控制程序的规模。语言的功能越强，生成程序的模块化和结构化程度越高，所需的指令数就越少，程序的可读性越好。,系统年龄：老系统随着不断的修改，结构越来越乱；维护人员经常更换，程序又变得越来越难于理解。许多老系统在当初并未按照软件工程的要求进行开发，因而没有文档，或文档太少。在长期的维护过程中文档在许多

6、地方与程序实现变得不一致，在维护时就会遇到很大困难。,数据库技术的应用：使用数据库，可以简单而有效地管理和存储用户程序中的数据，还可以减少生成用户报表应用软件的维护工作量。 先进的软件开发技术：在软件开发时，若使用能使软件结构比较稳定的分析与设计技术，及程序设计技术，如面向对象技术、复用技术等，可减少大量的工作量。,其它：应用的类型数学模型任务的难度开关与标记、IF嵌套深度、索引或下标数等对维护工作量都有影响。 许多软件在开发时并未考虑将来的修改，为软件的维护带来许多问题。,软件维护的策略,、改正性维护策略 开发过程中采用新技术，利用应用软件包，提高系统结构化程度，进行周期性维护审查等。,、适

7、应性维护策略 对可能变化的因素进行配置管理，将因环境变化而必须修改的部分局部化，即局限于某些程序模块等。,、完善性维护策略除了可以使用前面两类维护的策略外，还有使用功能强、使用方便的工具，采用原型化方法开发等，也可提高可维护性。,、预防性维护策略常采用提前实现、软件重用等技术。,8.2 软件维护的特点,8.2.1结构化维护与非结构化维护差别巨大,非结构化维护 软件配置的惟一成分是程序代码,缺乏必要的文档说明，文档缺少或者不一制，难于确定数据结构、系统接口等特性，这样的维护工作令人生畏，事倍功半。因此非结构化维护需要付出很大代价, 。,结构化维护 指软件开发过程是按照软件工程方法进行的，开发各阶

8、段的文档齐全，软件的维护过程，有一整套完整的方案、技术、审定过程及文档。因此易于维护。,8.2.2 维护的代价高昂维护阶段是软件生存期中最长的一个阶段，软件维护的工作量占整个软件生存期的70以上，而且还在逐年增加。 1970年用于维护已有软件的费用只占软件总预算的35%40%，1980年上升为40%60%，1990年上升为70%80%。 因此，如何减少软件维护的工作量，降低软件维护的成本，就成为提高软件维护效率和质量的关键。,维护成本,有形的软件维护成本是花费了多少钱，无形的维护成本有更大的影响。一些合理的修复或修改请求不能及时安排，使得客户不满意；变更的结果引入新的故障，使得软件整体质量下降

9、；把软件人员抽调到维护工作中，干扰了软件开发工作。,软件维护的代价是降低了生产率，在做老程序的维护时非常明显。 例如，开发每一行源代码耗资25美元，维护每一行源代码需要耗资1000美元。 维护工作量包括生产性活动（如分析和评价、设计修改和实现）和“非生产性”活动（如力图理解代码在做什么、试图判明数据结构、接口特性、性能界限等）。,维护工作量的模型,M是维护中消耗的总工作量 p是上面描述的生产性工作量 K是一个经验常数 c是因缺乏好的设计和文档而导致复杂性的度量 d是对软件熟悉程度的度量。,模型指明，如果使用了不好的软件开发方法（未按软件工程要求做），原来参加开发的人员或小组不能参加维护，则工作

10、量（及成本）将按指数级增加。,8.2.3 维护的问题很多,与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺点。在软件生命周期的头两个时期没有严格而又科学的管理和规划，几乎必然会导致在最后阶段出现问题。下面列出和软件维护有关的部分问题： （1）理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅速增加。如果仅有程序代码没有说明文档，则会出现严重的问题。,（2） 需要维护的软件往往没有合格的文档，或者文档资料显著不足。认识到软件必须有文档仅仅是第一步，容易理解的并且和程序代码完全一致的文档才真正有价值。 （3） 当要求对软件进行维护时，不能指望由开发人员给我们仔

11、细说明软件。由于维护阶段持续的时间很长，因此，当需要解释软件时，往往原来写程序的人已经不在附近了。 （4） 绝大多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理的设计方法学，否则修改软件既困难又容易发生差错。,（5） 软件维护不是一项吸引人的工作。形成这种观念很大程度上是因为维护工作经常遭受挫折。 上述种种问题在现有的没采用软件工程思想开发出来的软件中，都或多或少地存在着。不应该把一种科学的方法学看做万应灵药，但是，软件工程至少部分地解决了与维护有关的每一个问题。,为了有效地进行软件维护，应事先就开始做组织工作。首先建立维护的机构申明提出维护申请报告的过程及评价的过程为每一个维护申

12、请规定标准的处理步骤建立维护活动的登记制度以及规定评价和评审的标准。,8.3 软件维护过程,除了较大的软件开发公司外，通常在软件维护工作方面，并不保持一个正式的组织机构。 虽然不要求建立一个正式的维护组织，但是在开发部门确立一个非正式的维护组织则是非常必要的。,1. 维护组织,维护要求提交给维护管理员，他把申请交给某个相应的系统管理员去评价。 一旦做出评价，由变化授权人确定如何进行修改。 在修改程序的过程中，由配置管理员严格把关，控制修改的范围，对软件配置进行审计。 在维护之前，就把责任明确下来，可以减少维护过程中的混乱。,2. 维护报告,维护申请报告或称软件问题报告，由申请维护的用户填写。

13、用户必须完整地说明产生错误的情况，包括输入数据、错误清单以及其它有关材料。 如果申请的是适应性维护或完善性维护，用户必须提出一份修改说明书，列出所有希望的修改。,维护申请报告将由维护管理员和系统管理员来研究处理。 他们应相应地做出软件修改报告，指明：所需修改变动的性质；申请修改的优先级；为满足某个维护申请报告，所需的工作量；预计修改后的状况.,软件修改报告应提交修改负责人，经批准后才能开始进一步安排维护工作。,3. 维护的工作流程,尽管维护申请的类型不同，但都要进行同样的技术工作。修改软件需求说明修改软件设计设计评审对源程序做必要的修改单元测试集成测试( 回归测试)确认测试软件配置评审等。,在

14、每次软件维护任务完成后进行情况评审，对以下问题做一总结： (1) 在目前情况下，设计、编码、测试中的哪一方面可以改进? (2) 哪些维护资源应该有但没有? (3) 工作中主要的或次要的障碍是什么? (4) 从维护申请的类型来看是否应当有预防性维护? 情况评审对将来的维护工作如何进行会产生重要的影响。,4、维护档案记录,程序名称 源程序语句条数 机器代码指令条数 所用的程序设计语言 程序安装的日期 程序安装后的运行次数 与程序安装后运行次数有关的处理故障次数,程序改变的层次及名称 修改程序增加的源程序语句条数 修改程序减少的源程序语句条数 每次修改所付出的“人时”数 修改程序的日期 软件维护人员

15、的姓名 维护申请报告的名称、维护类型 维护开始时间和维护结束时间、 花费在维护上的累计“人时”数 维护工作的净收益等。,5、维护评价,评价维护活动比较困难，因为缺乏可靠的数据。 如果维护的档案记录做得比较好，可以得出一些维护“性能”方面的度量值。每次程序运行时的平均出错次数；花费在每类维护上的总“人时”数；,每个程序、每种语言、每种维护类型的程序平均修改次数；因为维护，增加或删除每个源程序语句所花费的平均“人时”数；用于每种语言的平均“人时”数；维护申请报告的平均处理时间；各类维护申请的百分比。据此可对开发技术、语言选择、维护工作计划、资源分配、以及其它许多方面做出判定。,8.4 软件的可维护

16、性,可以把软件的可维护性定性地定义为： 维护人员理解、改正、改动或改进这个软件的难易程度。,8.4.1 决定软件可维护性的因素,决定软件可维护性的因素主要有下述5个：,1. 可理解性,可理解性表明人们通过阅读源代码和相关文档，了解程序功能及其如何运行的容易程度。 一个可理解的程序应具备以下一些特性：模块化，风格一致性，不使用令人捉摸不定或含糊不清的代码，使用有意义的数据名和过程名，结构化，完整性等。,2. 可测试性,可测试性表明论证程序正确性的容易程度。程序越简单，证明其正确性就越容易。而且设计合用的测试用例，取决于对程序的全面理解。 一个可测试的程序应当是可理解的，可靠的，简单的。 用于可测试性度量的检查项目如下：程序是否模块化? 结构是否良好?,程序是否可理解? 程序是否可靠?程序是否能显示任意中间结果?程序是否能以清楚的方式描述它的输出?程序是否能及时地按照要求显示所有的输入?程序是否有跟踪及显示逻辑控制流程的能力?程序是否能从检查点再启动?程序是否能显示带说明的错误信息?,