基于任务驱动模式的软件工程与UML建模技术项目六软件交付与维护课件.ppt

《基于任务驱动模式的软件工程与UML建模技术项目六软件交付与维护课件.ppt》由会员分享，可在线阅读，更多相关《基于任务驱动模式的软件工程与UML建模技术项目六软件交付与维护课件.ppt（39页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、项目六 软件交付与维护 项目六 软件交付与维护 任务一任务一 软件交付软件交付 任务二任务二 软件维护软件维护 项目六 软件交付与维护 任务一任务一 软软 件件 交交 付付 操作一操作一 软件交付准则软件交付准则计算机软件的交付阶段是继计算机软件的需求、设计、编码、测试等阶段之后的一个核对用户需求、检验软件产品、面向客户实施应用的阶段。本阶段后期的工作旨在通过对计算机软件产品客户方的安装、应用及维护，收集计算机软件产品运行期出现的问题，及时反馈用户的使用信息，并转化为计算机软件产品的升级换代的重要性材料。项目六 软件交付与维护 操作二操作二 软件交付过程软件交付过程1对计算机软件项目进行交付前

2、的最终评审对计算机软件项目进行交付前的最终评审这部分工作主要包括：(1)核对软件项目开发周期各阶段形成文档的完整性。这些阶段性文档包括：需求阶段：需求规格说明书项目开发计划可行性研究报告产品设计说明书产品发布计划用户手册操作手册。设计阶段：概要设计说明书数据字典详细设计说明书数据库设计说明书、测试计划质量保证计划质量配置方案。项目六 软件交付与维护 编码阶段：测试报告。测试阶段：测试报告。(2)评审阶段性文档的真实性、有效性。各阶段文档应当反映出所处阶段的工作特点、待完成的工作指标和工作任务，符合软件生命周期各阶段的具体工作要求。项目六 软件交付与维护 项目六 软件交付与维护(2)评审最终产品

3、在逻辑设计上是否完全覆盖了用户的需求。全面检查概要设计说明书数据字典详细设计说明书和数据库说明书中对各个功能模块的定义是否符合用户需求，各技术说明书之间是否严格按照阶段性划分对模块进行定义，彼此之间是否存在着功能调用上的联系；检查各模块所用到的系统级参数的传递定义是否完全符合用户对需求的要求。对于新功能的增加部分，要严格同产品设计说明书、产品发布计划用户手册和操作手册进行比较，从模块定义、接口设计、数据及数据库定义等方面检查是否同以上文档的阐述内容相吻合。项目六 软件交付与维护(3)评审最终产品在软件的测试上是否完全覆盖了用户的操作需求。核对单元测试记录报告，检查模块测试接口覆盖率、错误测试覆

4、盖率、代码覆盖率。核对集成测试记录报告，验收测试记录报告，并检查测试范围是否覆盖了用户的全部需求；对于增加部分的功能测试，要核对是否与技术文档(概要设计说明书数据字典详细设计说明书和数据库说明书)和非技术文档(产品设计说明书产品发布计划用户手册和操作手册)相应部分的说明吻合。(4)安排、评审最终产品后期维护的准备工作。项目六 软件交付与维护 任务二任务二 软软 件件 维维 护护 操作一操作一 软件维护概念软件维护概念1.软件维护定义软件维护定义一般认为，软件维护就是在软件运行维护阶段，为了改正软件错误，或为了满足用户新的应用需要，而对软件进行改错、变更或进化的过程。具体地说，软件维护涉及以下几

5、个方面的任务。(1)改正性维护。由于软件测试技术的限制，已投入使用的软件必然会有一些隐藏的错误或缺陷。这些隐藏的错误或缺陷，在某些特定的使用环境下可能会暴露出来，并有可能影响到软件的正常使用。因此，软件技术人员需要对暴露出来的软件错误进行诊断，并设法改正这个错误。这个诊断与改正错误的过程，就叫做改正性维护。项目六 软件交付与维护 项目六 软件交付与维护 大多数软件维护活动的表现是：在软件运行阶段初期，改正性维护的工作量较大，而随着软件错误发现率的降低，软件系统的工作逐步趋于稳定，改正性维护也就由此下降。然而，随着软件使用时间的增加，用户新的需求意愿会逐渐形成并提出，于是软件适应性维护和完善性维

6、护的工作量就会逐步增加。除了上述三种类型的维护活动之外，还有一种叫做预防性维护的活动，这是为了使软件具有更好的可维护性、可靠性，或为了今后软件进化的便利而进行的一系列与维护有关的准备性工作。有关统计数据表明，在上述几种维护活动中，完善性维护所占的比重最大，约占整个维护工作的50%以上。预防性维护则只占很小的比例。也就是说，大部分的软件维护工作是扩充功能、提高性能，而不是改正错误。项目六 软件交付与维护 2.影响维护工作的因素影响维护工作的因素有关统计数据显示，软件维护活动所消耗的工作量占整个软件生存期工作量的70%以上。许多软件开发机构就因为软件维护工作量的巨大，而导致新的软件项目不能承接，新

7、的软件产品不能及时开发。软件维护需要消耗这么大的工作量，其原因是什么呢？有关研究表明，影响软件维护工作量的原因，归纳起来主要有以下几个方面。(1)系统大小：软件系统越大，其执行功能越复杂，理解掌握起来越困难，因而需要更多的维护工作量。(2)程序设计语言：许多软件是用较老的程序设计语言编写的，程序逻辑复杂、混乱，而且没有做到模块化和结构化，直接影响到程序的可读性与可维护性。项目六 软件交付与维护 项目六 软件交付与维护 3.非结构化与结构化维护非结构化与结构化维护1)非结构化维护非结构化维护往往与早期软件非工程化开发有关系，是软件开发过程中没有按照软件工程原则实施软件开发的后遗症。许多早期软件，

8、由于没有按照软件工程原则实施软件开发，以致和软件配套的一系列文档没有建立起来，保留下来的可能只有源程序。应该说，软件开发过程中文档的完整性，对软件今后的维护有非常大的影响。如果软件配置仅仅只有源程序代码，那么软件维护活动就需要直接从源程序代码开始。显然，面对这样的软件进行维护，将会是困难重重，而且往往还会使程序变得更加混乱，更加不能理解。项目六 软件交付与维护 项目六 软件交付与维护 而在软件维护具体实施过程中，则可以先修改设计，并且对所做的改动进行仔细复查，接下来编写相应的源程序代码，然后再依据测试说明书中包含的信息进行回归测试，最后把修改后的软件再次交付使用。很显然，结构化的维护是一种有利

9、于系统健康发展的维护，并能够在减少维护工作量、提高维护效率等方面产生积极作用。项目六 软件交付与维护 操作二操作二 软件维护的实施软件维护的实施1.维护机构维护机构随着软件维护工作量的不断增加，许多软件开发单位开始意识到了设立软件维护机构的重要性。这种维护机构有可能是一个临时维护小组，也有可能是一个长期专门从事软件维护的职能部门。一个临时维护小组往往被派去执行一些特殊的或临时的维护任务，例如，当正在工作的软件系统出现了不能回避的严重运行错误时，可能需要临时组织一个维护小组前往用户单位对系统进行排错检查。对于一个需要长期稳定运行的复杂系统，维护工作需要有一个相对稳定的维护部门来完成。项目六 软件

10、交付与维护 项目六 软件交付与维护(4)维护管理员：负责同软件开发部门或其他部门的联系，收集、整理有关维护的信息。(5)维护技术人员：负责分析程序错误、进行程序修正。为使维护工作正常开展，上述维护人员需要协作工作，例如可以按照下面的协作关系与工作步骤实施对软件的维护。(1)有关人员将维护申请报告表提交给维护管理员登记。(2)维护管理员把维护申请报告交系统监督员进行技术性评价。(3)系统监督员从技术角度对该项维护的可行性、必要性等做出说明。项目六 软件交付与维护(4)在得到系统监督员的技术性评价之后，维护管理员把维护申请报告表提交给维护机构负责人。(5)维护机构负责人将根据对维护申请报告的技术评

11、价，决定如何进行软件维护。(6)维护机构负责人需要将维护决定通知维护管理员，以便维护管理员能够及时安排相关技术人员实施维护。(7)维护机构负责人还需要将维护决定通知配置管理员，以便技术人员在对系统进行维护的过程中，配置管理员能够严格把关，控制维护范围，并对软件配置进行审计。图6-1是维护工作人员之间的协作关系图示说明。项目六 软件交付与维护 图6-1 维护工作人员协作关系图项目六 软件交付与维护 2.维护申请报告维护申请报告为使维护按规程进行，需要先以文档的形式提出维护申请，例如，由申请维护的人员(用户、开发人员)填写一份软件维护申请报告表。对于改正性维护，申请报告必须尽量完整地说明错误产生的

12、情况，包括运行时的环境、输入数据、错误提示等。对于适应性或完善性的维护，则应该提交一份简要的维护要求说明。一切维护活动都应该从维护申请报告开始，并需要由维护机构对维护请求进行评审，由此确定维护类型(改正性维护、适应性维护或完善性维护)，然后根据需要维护的软件问题的严重性，对维护作出具体的工作安排。项目六 软件交付与维护 在维护过程中，软件维护机构内部还应该制定一份软件修改报告，该报告是维护阶段的技术性文档，其一般包含以下信息：(1)维护工作量；(2)维护类型；(3)维护的优先顺序；(4)预见的维护结果。项目六 软件交付与维护 项目六 软件交付与维护(3)对于适应性维护和完善性维护申请，需要先确

13、定每项申请的优先次序。若某项申请的优先级非常高，就可立即开始维护工作，否则，将维护申请纳入软件开发任务计划进行排队(适应性维护与完善性维护可当作开发看待)，统一安排维护时间。项目六 软件交付与维护 图6-2 软件维护工作流程项目六 软件交付与维护 尽管维护申请的类型不同，但都要进行同样的技术工作。这些工作有：修改软件需求说明，修改软件设计，设计评审，对源程序做必要的修改，单元测试，集成测试(回归测试)，确认测试，软件配置评审等。在每次软件维护任务完成之后，应该对维护情况进行评审。评审内容包括：(1)设计、编码、测试中的哪些方面还可以改进；(2)哪些维护资源应该有，但事实上却没有；(3)维护工作

14、中主要的或次要的障碍是什么；(4)是否需要考虑预防性维护。维护情况评审对今后维护工作的进行有重要的影响，并可为软件机构的有效管理提供重要的反馈信息。项目六 软件交付与维护 项目六 软件交付与维护 5.维护评价维护评价由于缺乏可靠的数据，评价维护活动往往比较困难。但如果维护的档案记录做得比较好，就可以得出一些维护“性能”方面的度量值。可参考的度量值如：(1)每次程序运行时的平均出错次数；(2)花费在每类维护上的总“人时”数；(3)每个程序、每种语言、每种维护类型的程序平均修改次数；(4)因为维护，增加或删除每个源程序语句所花费的平均“人时”数；项目六 软件交付与维护(5)用于每种语言的平均“人时

15、”数；(6)维护申请报告的平均处理时间；(7)各类维护申请的百分比。这7种度量值提供了定量的数据，据此可对开发技术、语言选择、维护工作计划、资源分配以及其他许多方面做出判定，因此，这些数据可以用来评价维护工作。一个应用广泛的可维护性评估模型是：通过对可理解性、可靠性、可测试性、可修改性、可移植性、运行效率和可使用性这7个方面的软件特性的评价，对软件的可维护性进行综合评估。项目六 软件交付与维护 项目六 软件交付与维护(5)可移植性：指程序转移到一个新的计算环境的可能性的大小。一个可移植的程序应具有结构良好、灵活，并具有与计算机、操作系统无关的特点。(6)运行效率：指一个程序能执行预定功能而又不

16、浪费机器资源的程度。这些机器资源包括：内存容量、外存容量、通道容量和执行时间。(7)可使用性：指对于用户而言，程序的方便、实用和易于使用的程度。需要注意的是，上述7个方面的软件特性，对于不同类型的软件维护，会有不同的侧重表现。表6-1显示了各类维护中应该侧重的特性。项目六 软件交付与维护 表表6-1 各类维护侧重特性一览表各类维护侧重特性一览表项目六 软件交付与维护 操作三操作三 软件配置管理软件配置管理软件配置管理是一组针对软件产品的追踪和控制活动，它贯穿于软件生命周期的始终，并代表软件产品接受各项评审。当对软件进行维护时，软件产品发生了变化，这一系列的改变，必须在软件配置中体现出来，以防止

17、因为维护所产生的变更给软件带来混乱。软件开发过程中，需要输出的信息有以下三种：计算机程序，描述计算机程序的文档，数据结构。软件配置就由这些信息所组成。项目六 软件交付与维护 1.配置标识配置标识为了方便对软件配置中的各个对象进行控制与管理，首先应给它们命名，再利用面向对象的方法组织它们。通常需要标识两种类型的对象：基本对象和复合对象。基本对象是由软件工程师在分析、设计、编码和测试时所建立的“文本单元”。复合对象则是基本对象或其他复合对象的一个集合。每个对象可用一组信息来唯一地标识它，这组信息包括名字、描述、资源、实现等内容。项目六 软件交付与维护 2.变更控制变更控制软件生命期内全部的软件配置

18、是软件产品的真正代表，必须使其保持精确。软件工程过程中某一阶段的变更，均要引起软件配置的变更，这种变更必须严格加以控制和管理，以保证修改信息能够精确、清晰地传递到软件工程过程的下一步骤。变更控制包括建立控制点和建立报告与审查制度。在此过程中，首先由用户提交书面的变更请求，详细申明变更的理由、变更方案、变更的影响范围等。然后由变更控制机构确定控制变更的机制、评价其技术价值、潜在的副作用、对其他配置对象和系统功能的综合影响以及项目的开销，并把评价的结果以变更报告的形式提交给变更控制负责人进行变更确认。项目六 软件交付与维护 软件的变更通常有两类不同的情况：(1)为改正小错误需要的变更。它是必须进行

19、的，通常不需要从管理角度对这类变更进行审查和批准。但是，如果发现错误的阶段在造成错误的阶段后面，例如在实现阶段发现了设计错误，则必须遵照标准的变更控制过程，把这个变更正式记入文档，把所有受这个变更影响的文档都做相应的修改。项目六 软件交付与维护(2)为了增加或者删掉某些功能，或者为了改变完成某个功能的方法而需要的变更。这类变更必须经过某种正式的变更评价过程，以估计变更需要的成本和它对软件系统其他部分的影响。如果变更的代价比较小且对软件系统其他部分没有影响或影响很小，通常应批准这个变更。反之，如果变更的代价比较高或者影响比较大，则必须权衡利弊，以决定是否进行这种变更。如果同意这种变更，需要进一步确定由谁来支付变更所需要的费用。如果是用户要求的变更，则用户应支付这笔费用，否则，必须完成某种成本/效益分析，以确定是否值得做这种变更。应该把所做的变更正式记入文档，并相应地修改所有相关的文档。项目六 软件交付与维护 3.版本控制版本控制软件变更往往会带来软件版本的改变与新版本的发布，对此，需要进行有效的控制。版本控制往往利用工具来进行管理与标识，并有许多不同的自动版本控制方法。图6-3所示是用于表现系统不同版本的演变图。图中的各个结点都是一个用于反映版本完整组成的聚合对象，是源代码、文档、数据的一次完整收集。项目六 软件交付与维护 图6-3 不同版本的系统演变图