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