软件工程第7章--软件维护与再工程课件

,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,2020/4/3,#,单击此处编辑母版标题样式,第,7,章,软件维护与再工程,软件维护分类,软件可维护性,软件维护实施,软件再工程,第7章 软件维护与再工程软件维护分类,1,1.,软件维护分类,所谓软件维护,就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程,。,可以,通过描述软件交付使用后可能进行,的以下,4,项活动，具体地定义软件维护。,改正性维护,完善性维护,适应性维护,预防性维护,1.软件维护分类 所谓软件维护就是在软件已经交付使用之后，,2,改正性维护,因为软件测试不可能暴露出一个大型软件系统中所有潜藏的错误，所以必然会有,第一项维护活动,：,在任何大型程序的使用期间，用户必然会发现程序错误，并且把他们遇到的问题报告给维护人员。把诊断和改正错误的过程称为改正性维护。,改正性维护 因为软件测试不可能暴露出一个大型软件,3,适应性维护,第二项维护,活动,实际寿命,预期寿命,旧版本,增加,修改,因此，适应性维护，也就是为了和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动。,适应性维护第二项维护活动实际寿命预期寿命旧版本增加修改因,4,完善性,维护,当一个软件系统顺利地运行时，常常出现,第三项维护活动,：在使用软件的过程中用户往往提出增加新功能或修改已有功能的建议，还可能提出一般性的改进意见。为了满足这类要求，需要进行完善性维护。这项维护活动通常占软件维护工作的大部分。,完善性维护 当一个软件系统顺利地运行时，常常出现,5,预防性维护,当为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件时，出现了,第四项维护活动,。这项维护活动通常称为预防性维护，目前这项维护活动相对比较少。,预防性维护 当为了改进未来的可维护性或可靠性，或,6,2.,软件可维护性,可以把软件的可维护性定性地定义为：维护人员理解、改正、改动或改进这个软件的难易程度。,影响,软件可维护性的因素有：系统大小、系统文档、系统年龄。,可通过软件的易理解性、可靠性、易修改性、易移植性的评价，而对软件系统进行可维护性综合评估。,2.软件可维护性可以把软件的可维护性定性地定义为：维护人,7,决定软件可维护性的,因素,维护就是在软件交付使用后进行的修改，,修改之前必须理解待修改的对象，修改之后应该进行必要的测试,，以保证所做的修改是正确的。如果是改正性维护，还必须预先进行调试以确定错误的具体位置。因此，决定软件可维护性的因素主要有下述,5,个。,可理解性,可测试性,可修改性,可移植性,可重用性,决定软件可维护性的因素维护就是在软件交付使用后进行的修改，修,8,1.,可理解性,软件可理解性表现为外来读者理解软件的结构、功能、接口和内部处理过程的难易程度。,模块化（模块结构良好，高内聚，松耦合）、详细的设计文档、结构化设计、程序内部的文档和良好的高级程序设计语言等，都对提高软件的可理解性有重要贡献。,1.可理解性 软件可理解性表现为外来读者理解软,9,2,.,可测试性,诊断和测试的容易程度取决于软件容易理解的程度。,良好的文档,软件结构,可用的测试工具,调试工具，,以前设计的测试过程,开发阶段用过的测试方案，以便维护人员进行回归测试。,在设计阶段应该尽力把软件设计成容易测试和容易诊断的。,对于程序模块来说，可以用程序复杂度来度量它的可测试性。模块的环形复杂度越大，可执行的路径就越多，因此，全面测试它的难度就越高。,2.可测试性诊断和测试的容易程度取决于软件容易理解的程度。,10,3.,可修改性,软件容易修改的程度和本书第,5,章讲过的设计原理和启发规则直接有关。耦合、内聚、信息隐藏、局部化、控制域与作用域的关系等，都影响软件的可修改性。,4.,可移植性,软件可移植性指的是，把程序从一种计算环境（硬件配置和操作系统）转移到另一种计算环境的难易程度。把与硬件、操作系统以及其他外部设备有关的程序代码集中放到特定的程序模块中，可以把因环境变化而必须修改的程序局限在少数程序模块中，从而降低修改的难度。,3.可修改性 软件容易修改的程度和本书第5章讲,11,5.,可重用性,所谓重用（,reuse,）是指同一事物不做修改或稍加改动就在,不同环境中多次重复使用,。大量使用可重用的软件构件来开发软件，可以从下述两个方面提高软件的可维护性。,(1),通常，可重用的软件构件在开发时都经过很严格的测试，可靠性比较高，且在每次重用过程中都会发现并清除一些错误，随着时间推移，这样的构件将变成实质上无错误的。因此，软件中使用的可重用构件越多，软件的可靠性越高，改正性维护需求就越少。,(2),很容易修改可重用的软件构件使之再次应用在新环境中，因此，软件中使用的可重用构件越多，适应性和完善性维护也就越容易。,5.可重用性 所谓重用（reuse）是指同一事,12,文档,文档可以分为,用户文档,和,系统文档,两类。,1.,用户文档,用户文档是用户了解系统的第一步，它应该能使用户获得对系统的准确的初步印象。,(1),功能描述,(2),安装文档,(3),使用手册,(4),参考手册（要完整）,(5),操作员指南,(,如果需要有系统操作员的话,),文档文档可以分为用户文档和系统文档两类。,13,2.,系统文档,所谓系统文档指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是极端重要的。,和用户文档类似，系统文档的结构也应该能把读者从对系统概貌的了解，引导到对系统每个方面每个特点的更形式化更具体的认识,。,2.系统文档 所谓系统文档指从问题定义、需求,14,可维护性,复审,可维护性是所有软件都应该具备的基本特点，必须在开发阶段保证软件,具有可,维护因素。,在完成了每项维护工作之后，都应该对软件维护本身进行仔细认真的复审。,不能准确反映软件当前状态的设计文档可能比完全没有文档更坏。,如果对软件的可执行部分的修改没有及时反映在用户文档中，则必然会使用户因为受挫折而产生不满。,为什么要进行可维护性复审？,可维护性复审可维护性是所有软件都应该具备的基本特点，必须在开,15,在软件再次交付使用之前，对软件配置进行严格的复审，则可大大减少文档的问题。,在需求分析阶段的复审过程中,，应该对将来要改进的部分和可能会修改的部分加以注意并指明；应该讨论软件的可移植性问题，并且考虑可能影响软件维护的系统界面。,在正式的和非正式的设计复审期间,，应该从容易修改、模块化和功能独立的目标出发，评价软件的结构和过程；设计中应该对将来可能修改的部分预作准备。,在软件再次交付使用之前，对软件配置进行严格的复审，则可大大减,16,代码复审,应该强调编码风格和内部说明文档这两个影响可维护性的因素。,在设计和编码过程中,应该尽量使用可重用的软件构件，如果需要开发新的构件，也应该注意提高构件的可重用性。,在测试结束时,进行最正式的可维护性复审，这个复审称为,配置复审,。配置复审的目的是保证软件配置的所有成分是完整的、一致的和可理解的，而且为了便于修改和管理已经编目归档了。,代码复审应该强调编码风格和内部说明文档这两个影响可维护性的因,17,3.,软件维护实施,开发组可承担软件初期维护，但当软件转入正常使用以后，其维护工作则一般由专门的维护机构承担。软件维护机构人员组成有：维护负责人、系统监督员、配置管理员、维护工程师。其中，维护负责人全权负责维护任务，包括技术与管理两个方面的工作。,维护将由申请报告启动，其一般由软件用户提出。维护机构则对维护申请进行评审。维护活动需要记录存档，需要进行评价。,3.软件维护实施开发组可承担软件初期维护，但当软件转入正常,18,维护实施过程,本质上是修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。,首先必须建立一个维护组织,随后必须确定报告和评价的过程,而且必须为每个维护要求规定一个标准化的事件序列,此外，还应该建立一个适用于维护活动的记录保管过程，并且规定复审标准。,维护实施过程,的本质,维护实施过程本质上是修改和压缩了的软件定义和开,19,1.,维护组织,虽然通常并不需要建立正式的维护组织，但是，即使对于一个小的软件开发团体而言，非正式地委托责任也是绝对必要的。,每个维护要求都通过,维护管理员,转交给熟悉该产品的,系统管理员,去评价。系统管理员是被指定去熟悉一小部分产品程序的,技术人员,。系统管理员对维护任务做出评价之后，由,变化授权人,决定应该进行的活动。,在维护活动开始之前就明确维护责任是十分必要的，这样做可以大大减少维护过程中可能出现的混乱。,维护管理员,系统管理员,程序技术人员,变化授权人,转交维护要求,指定维护人员,评价后上交，促成决定活动,1.维护组织 虽然通常并不需要建立正式的维护组,20,2,.,维护报告,应该用标准化的格式表达所有软件维护要求。,软件维护人员通常给用户提供空白的,维护要求表,有时称为软件问题报告表，这个表格由要求一项维护活动的用户填写。如果遇到了一个错误，那么必须完整描述导致出现错误的环境,(,包括输入数据、全部输出数据以及其他有关信息,),。,对于适应性或完善性的维护要求，应该提出一个简短的需求说明书。如前所述，由维护管理员和系统管理员评价用户提交的维护要求表。,2.维护报告 应该用标准化的格式表达所有软件维,21,维护要求表是一个外部产生的文件，它是计划维护活动的基础。软件组织内部应该制定出一个软件修改报告，它给出下述信息。,(1),满足维护要求表中提出的要求所需要的工作量。,(2),维护要求的性质。,(3),这项要求的优先次序。,(4),与修改有关的事后数据。,在拟定进一步的维护计划之前，把软件修改报告提交给变化授权人审查批准。,维护要求表是一个外部产生的文件，它是计划维护活,22,3,.,维护的事件流,右,图描绘,了一项维护要求而引出的一串事件。,首先应该确定要求进行的维护的类型。用户常常把一项要求看作是为了改正软件的错误,(,改正性维护,),，而开发人员可能把同一项要求看作是适应性或完善性维护。当存在不同意见时必须协商解决。,3.维护的事件流右图描绘了一项维护要求而引出的一串事件。,23,由上图可知，对一项改正性维护要求,(,图中“错误”通路,),的处理，从估量错误的严重程度开始。如果是一个严重的错误，则在系统管理员的指导下分派人员，并且立即开始问题分析过程。如果错误并不严重，那么改正性的维护和其他要求软件开发资源的任务一起统筹安排。,适应性维护和完善性维护的要求沿着相同的事件流通路前进。应该确定每个维护要求的优先次序，并且安排要求的工作时间，就好像它是另一个开发任务一样。如果一项维护要求的优先次序非常高，可能立即开始维护工作。,由上图可知，对一项改正性维护要求(图中“错误”,24,不管维护类型如何，都需要进行同样的技术工作。包括：,修改软件设计、复查、必要的代码修改、单元测试和集成测试,(,包括使用以前的测试方案的回归测试,),、验收测试和复审,。,不同类型的维护强调的重点不同，但是基本途径是相同的。维护事件流中最后一个事件是复审，它再次检验软件配置的所有成分的有效性，并且保证事实上满足了维护要求表中的要求。,不管维护类型如何，都需要进行同样的技术工作。包括,25,软件维护工作流程如左图所示。,软件维护工作流程如左图所示。,26,在完成软件维护任务之后，进行处境复查常常是有好处的。一般说来，这种复查试图回答下述问题。,在当前处境下设计、编码或测试的哪些方面能用不同方法进行,?,哪些维护资源是应该有而事实上却没有的,?,对于这项维护工作什么是主要的,(,以及次要的,),障碍,?,要求的维护类型中有预防性维护吗,?,处境复查对将来维护工作的进行有重要影响，而且所提供的反馈信息对有效地管理软件组织十分重要。,在完成软件维护任务之后，进行处境复查常常是有好,27,4.,保护维护记录,Swanson,提出了：,1,程序标识；,2