《软件工程》课件第13章

第13章软件维护了解维护的概念，掌握四类维护了解维护过程、软件的可维护性ZLL第13章 软件维护软件维护是软件生命周期的最后一个阶段，软件从部署完毕到退役的整个时间内对软件的改动所做的工作都是维护的内容。在项目的各个阶段对项目的可维护性进行充分考虑、对可维护性的严格评审以及在维护阶段有效地组织和管理维护活动，则是保证软件可维护性和降低维护费用的关键。本章重点内容：维护的主要内容、维护的流程、如何在软件的生产过程各个阶段保证软件的可维护性目标。ZLL13.1软件维护概述软件维护的主要目标是使已部署的软件按照需求规格说明书的要求（或用户的新需求）运行，这要求软件不仅要满足用户所需要的各项功能需求，同时还要满足用户对软件的非功能需求。软件维护的基本内容则包含了实现这些目标所做的全部工作。ZLL13.1.1软件维护的定义按照维护的起因分类：纠错性维护适应性维护改善性维护预防性维护四类。1.纠错性维护——为改正软件系统中潜藏的错误而进行的活动。用户在使用软件过程中发现软件的错误是激发该种维护的起因。四类ZLL2.适应性维护——为适应软件运行环境的变化而修改软件的活动。软件的运行环境包括两个方面，硬件和软件，软件则大体上包括操作系统、中间件、虚拟机等等。13.1.1软件维护的定义ZLL3.改善性维护——根据用户在软件使用过程中提出的建设性意见而进行的维护活动。主要是针对用户提出的新的软件需求或修改原有的软件需求而进行的维护，该种维护通常占所有维护工作量的一半以上。软件在部署之后一段时间内，用户的改善性维护应该是递减的。13.1.1软件维护的定义ZLL4.预防性维护——为了进一步改善软件系统的可维护性和可靠性，并为以后的改进奠定基础。预防性维护可以采取逆向工程（reverseengineering）和重构工程（re-engineering）方式。13.1.1软件维护的定义ZLL严格按照软件工程标准生产的软件产品在维护过程中纠错性维护的工作量很低，不到总维护工作量的1／5。由于改善性维护和适应性维护需要修改需求规格说明书，应按照需求变更来进行管理，相当于螺旋模型中的又一次迭代过程，因此工作量很大。13.1.1软件维护的定义ZLL13.1.2影响维护工作的因素1．系统大小系统越大，越复杂，维护人员理解起来就越困难。因而需要更多的维护工作量。可用源程序语句数，输入输出文件数，实现的功能模块数量来衡量系统的大小。2．系统的开发文档系统的开发文档完善，维护工作就好做很多。开发文档不完善，则维护的工作量将会很大，因为要通过源程序去阅读，理解一个程序的功能和设计思想将是非常困难的。3．其他因素在程序中使用的数学模型、任务的难度、IF嵌套深度、索引或下标数等，对维护工作量都有影响。ZLL13.1.3维护成本软件的维护成本体现为有形和无形两类。有形的软件维护成本是花费了多少钱，无形的成本是对其他方面的影响，可以是以下几种：（1）维护不及时和不能满足用户新的功能需求，使得用户不满意。（2）在维护时因引入了新的错误，使软件整体质量下降，从而造成更大的维护活动。（3）当必须把软件人员抽调到维护工作中去时，影响正在进行的软件开发工作。软件维护的代价是在生产率（用LOC/PM或功能点/PM度量）方面惊人的下降。有报告说，生产率将降到原来的1/40。维护工作量可以分成生产性活动（如分析和评价，设计修改和实现）和“轮转”活动（如力图理解代码在做什么、试图判明结构、接口特性、性能界限等）。ZLL13.2软件可维护性对于一个复杂的软件系统，造成维护工作十分困难的一个直接原因是缺乏软件开发文档。因为没有足够的、规范的文档，很难理解以前的软件的功能、算法，很难阅读和理解源程序。但实际上，最根本的原因是没有严格按照软件工程的规范和标准来开发软件，在维护时也没有按照规范来做，为以后的维护带来了更多的问题。所以，为了使得软件能够易于维护，首先必须考虑使软件具有可维护性。ZLL13.2.1软件可维护性的定义

可维护性、可使用性、可靠性是衡量软件质量的几个主要质量特性，也是用户十分关心的几个方面。软件的可维护性是软件开发阶段各个时期的关键目标。目前广泛使用的是如下的七个特性来衡量软件的可维护性。而且对于不同类型的维护，这七种特性的侧重点也不相同。表13-1显示了在各类维护中应侧重哪些特性。表中的“√”表示特别需要的特性。软件可维护性就是指进行维护活动时的容易程度。类别改正性维护适应性维护完善性维护可理解性√可测试性√可修改性√√可靠性√可移植性√可使用性√√效率√ZLL13.2.2可维护性的度量在对软件质量的量化追求中，形成了一个新的学科——软件度量学。下面介绍度量一个可维护的程序的七种特性时常用的方法。这就是质量检查表、质量测试、质量标准。质量检查表是一个问题清单，评价者针对检查表上的每一个问题，依据自己的定性判断，回答“Yes”或“No”。用这个清单对质量进行分析。质量测试与质量标准则用于定量分析和评价程序的质量。下面是对这七种特性的描述。1．可理解性2．可靠性3．可测试性4．可修改性5．可移植性6．效率7．可使用性8．其他间接定量度量可维护性的方法Gilb提出了与软件维护期间工作量有关的一些数据，可以使用它们间接地对软件的可维护性做出估计。ZLL13.2.3可维护性复审可维护性是软件工程所追求的一个目标。在软件工程每一阶段的复审中，可维护性都是一个重要的指标。在需求分析阶段的复审中，应在规格说明书中对将来可能修改和可以改进的部分加以注明；在设计阶段的复审中，应该从易于维护和提高设计总体质量的角度对设计进行全面评审；代码复审主要审查代码风格和内部文档（程序注释等）这两个直接影响可维护性的因素。最后，每一阶段性测试（直到软件正式交付之前）都应该进行预防性的维护。正式的可维护性复审放在测试完成之后，称为配置复审。目的是保证配置中所有成分的完整、一致、易于理解且便于修改控制。ZLL13.3软件维护的特点1．非结构化维护因为只有源程序，而文档很少或没有文档，维护活动只能从阅读、理解和分析源程序开始。也只有通过阅读源程序来了解系统功能、软件结构、数据结构、系统接口和设计约束等。要完成这些工作是非常困难的。要想搞清楚，要花费大量的人力、物力，最终对源程序修改的后果还是难以估量的，难以估计软件的质量。因为没有测试文档，不可能进行回归测试，很难保证程序的正确性。2．结构化维护用软件工程思想开发的软件具有各个阶段的文档，这对于理解、掌握软件功能、性能、软件结构、数据结构、系统接口和设计约束有很大作用。进行维护活动时，需从评价需求说明开始，搞清楚软件功能、性能上的改变；对设计说明文档进行评价，对设计说明文档进行修改和复查；根据设计的修改，进行程序的变动；根据测试文档中的测试用例进行回归测试。ZLL是否维护要求评价设计阅读源代码计划途径定位错误修改设计重编程序重编程序交付使用回归测试是否结构化回归测试图13-1结构化维护和非结构化维护13.3软件维护的特点ZLL13.3.2维护的困难性（1）读懂别人的源程序是困难的。（2）文档的不一致性（3）软件开发和软件维护在人员和时间上的差异（4）软件维护不是一项具有吸引力的工作ZLL13.3软件维护的费用1990年1980年1970年占总费用的35%—40%占总费用的35%—40%占总费用的35%—40%

维护活动的总工作量由下式表示：M=P+K·exp(C–D)其中：M表示维护工作的总工作量（人年/人月）；P表示生产性活动工作量；K表示经验常数；C表示复杂性程度；D表示维护人员对软件的熟悉程度。上式表明，若C越大，D越小，那么维护工作量将成指数增加；C增加表示软件因未用软件工程方法开发，文档缺少，程序复杂性高；D表示对软件熟悉程度，如果维护人员不是开发人员，则重新理解软件会花费很多时间，造成总的维护费用上升。ZLL13.4软件维护的实施——13.4.1维护的组织

为软件维护活动建立维护机构，通常以维护小组形式出现，分为临时和长期两种类型。1．临时维护小组执行一些特殊的或临时的维护任务。例如，对程序排错的检查，检查完善性维护的设计和进行质量控制的复审等。无论临时维护小组的任务如何简单，给小组的成员清晰的责任应是很重要的，以免因为维护过程中的责任不清而造成混乱。2．长期维护小组对长期运行的复杂系统进行维护必须有一个稳定的维护小组才可以完成任务。维护小组在系统开发完成之前就应该成立，小组必须有严格的组织。一般有如下的组成成员：（1）组长组长应对维护小组的一切活动负责。负责向上级主管部门报告维护工作，并负责小组的维护工作管理。组长是该小组的技术负责人，有较高的技术水平，并具有一定的管理经验，熟悉系统的应用领域。（2）副组长副组长是组长的助手，具体负责同开发部门或其他维护小组联系。在系统开发阶段，收集与维护有关的信息；在维护阶段，他同开发者继续保持联系，向他们传送程序运行的反馈信息。因为在维护活动中的改正性维护大多是由用户提出的，所以副组长应该同用户保持密切联系。（3）维护程序员维护程序员负责分析程序的错误，并执行修改工作。要求维护程序员不仅熟悉编程，还应该具有软件开发和维护方面的知识和经验，还应熟悉程序应用领域的知识。ZLL13.4.2维护的流程软件维护活动和软件开发一样，要有严格的规范，才能保证软件的质量。一般执行维护活动的流程如下：（1）制定维护申请报告。（2）审查申请报告并批准。（3）进行维护并做详细记录。（4）复审。1．制定维护申请报告应该以文档的形式提出所有软件维护申请。由申请维护的人员填写。对于改正性的维护申请报告必须尽量完整地说明错误产生的场景，包括运行时的环境、输入数据、错误提示以及其他有关材料。但是要注意，由于设计的问题，对运行时出现的错误不一定再现。对于适应性或完善性的维护要求，则要提交一份简要的维护要求说明。一切维护活动都应该是从维护申请报告开始。对维护申请报告分析、评价后，在软件维护组织内部还要制定一份软件修改报告，该报告是维护阶段的另一种文档，用来指出：（1）为满足软件问题报告实际要求的工作量。（2）要求修改的类型。（3）请求修改的优先权。（4）关于修改的事后数据。提出维护申请报告之后，由维护机构来评审维护请求。将评价维护的类型，是改正性的还是改进性的，然后根据问题的严重性安排维护工作，适时开始具体的维护活动。ZLL13.4.2维护的流程2．维护过程一个维护申请提出之后，经评审需要维护，则按下列过程实施维护：（1）首先确定要进行维护的类型。要确定维护的类型是改正性的还是改进性的，从用户的观点和维护小组的观点出发得到的结果不一定是相同的。要与用户协商解决这个问题。（2）对改正性维护从评价错误的严重性开始。如果存在一个严重的错误（如一个系统的重要功能不能执行），则由管理人员立即组织有关人员开始分析问题。如果错误不严重，则将改正性维护与软件其他维护任务一起进行，统一安排维护工作。甚至经过评审后发现申请是错误的，并不需要进行维护活动。（3）对适应性和完善性维护。对问题进行评审，确定问题的优先级。如果优先级低，则看成是另一个开发工作，安排所要求的工作，如果优先级高，需要立即开始分析问题，进入此项维护工作。（4）实施维护任务。不管维护类型如何，大体上要开展相同的技术工作。这些工作包括分析软件的需求、修改软件设计、修改源程序、单元测试、集成测试、确认测试以及复审，在每个阶段都要有详细的文档。但是，对不同的维护类型，工作的侧重点不一样。（5）“救火”维护。对于有的维护申请，需要立即进行修改维护，这时申请的维护称为“救火”维护。显然，如果一个软件开发机构经常“救火”，就必须要认真检查一下，该机构的管理和技术存在什么重大问题。3．维护的复审在维护任务完成后，要对维护任务进行复审。进行复审时要回答下列问题：（1）评价维护的情况，即设计、编码和测试的哪些方面已经完成？（2）对软件开发工作有哪些改进要求？（3）对于维护工作，主要的、次要的障碍是什么？复审对将来的维护工作能否顺利进行有重大影响，对一个软件机构来说也是正规、有效的管理工作的一部分。ZLL13.4.3维护技术1．面向维护的技术——面向维护的技术涉及软件开发的所有阶段。在需求分析阶段，保证对用户的需求没有矛盾和易于理解，可以减少软件中的错误在设计阶段，考虑计算机的发展趋势，充分考虑将来改动或扩充的可能性。使用先进的设计思想和工具。在测试阶段，设计完善的测试方法，尽量发现存在的错误，保存测试用例和测试结果等。在每个阶段都要有详细、规范的文档，这些技术方法都能减少软件错误，提高软件的可维护性。2．维护支援技术维护支