软件工程第9章软件维护.ppt

上传人:李司机 文档编号:4096118 上传时间:2023-04-04 格式:PPT 页数:36 大小:773KB
返回 下载 相关 举报
软件工程第9章软件维护.ppt_第1页
第1页 / 共36页
软件工程第9章软件维护.ppt_第2页
第2页 / 共36页
软件工程第9章软件维护.ppt_第3页
第3页 / 共36页
软件工程第9章软件维护.ppt_第4页
第4页 / 共36页
软件工程第9章软件维护.ppt_第5页
第5页 / 共36页
点击查看更多>>
资源描述

《软件工程第9章软件维护.ppt》由会员分享,可在线阅读,更多相关《软件工程第9章软件维护.ppt(36页珍藏版)》请在三一办公上搜索。

1、软件维护,第 九 章,9,9.1 软件维护的基本概念,软件维护是指软件系统交付使用以后,为了改正错误或满足新的需求而修改软件的过程。软件维护工作处于软件生命期的最后阶段,维护阶段是软件生存期中最长的一个阶段,所花费的人力、物力最多,其花费高达整个软件生命期花费的约60-70。因为计算机程序总是会发生变化,对隐含错误的修改,新功能的加入,环境变化造成的程序变动等。因此,应该充分认识到维护工作的重要性和迫切性,提高软件的可维护性,减少维护的工作量和费用,延长已经开发软件的生命期,以发挥其应有的效益。,9.1.1 软件维护的目的,1.在运行中发现在测试阶段未能发现的潜在软件错误和设计缺陷;2.根据实

2、际情况,需要改进软件设计,以增强软件的功能,提高软件的性能;3.要求在某环境下已运行的软件能适应特定的硬件、软件、外部设备和通信设备等新的工作环境,或是要求适应已变动的数据或文件;4.为使投入运行的软件与其它相关的程序有良好的接口,以利于协同工作;5.为使运行软件的应用范围得到必要的扩充。,9.1.2 软件维护的类型,按照不同的维护目的,维护工作可分成4类。,完善性维护(Perfective Maintenance)扩充原有系统的功能,提高原有系统的性能,满足用户的实际需要。纠错性维护(Corrective Maintenance)对在测试阶段未能发现的,在软件投入使用后才逐渐暴露出来的错误的

3、测试、诊断、定位、纠错以及验证、修改的回归测试过程。,一、软件维护的类型,软件维护的类型,适应性维护(Adaptive Maintenance)要使运行的软件能适应运行环境的变动而修改软件的过程。预防性维护(Preventive Maintenance)为了进一步改善软件的可靠性和易维护性,或者为将来的维护奠定更好的基础而对软件进行修改。,四类软件维护的比例,9.1.3 软件维护的特性,1.时间长、工作量大、成本高 软件的维护过程是软件生存期中最长,并且相当困难的阶段,软件维护的工作量占整个软件生存期的70%以上,而且还在逐年增加。因此,如何减少软件维护的工作量,降低软件维护的成本,就成为提高

4、软件维护效率和质量的关键。2.维护的副作用(1)修改代码的副作用。在修改源代码时,由于软件的内在结构等原因,任何一个小的修改都可能引起的错误。因此在修改时必须特别小心。,9.1.3 软件维护的特性,(2)修改数据的副作用。在修改数据结构时,有可能造成软件设计与数据结构不匹配,因而导致软件出错。数据副作用就是修改软件信息结构导致的结果。修改数据副作用可以通过详细的设计文档加以控制,此文档中描述了一种交叉作用,把数据元素、记录、文件和其他结构联系起来。(3)修改文档的副作用。对软件的数据流、软件结构、模块逻辑等进行修改时,必须对相关技术文档进行相应修改。但修改文档过程会产生新的错误,导致文档与程序

5、功能不匹配,缺省条件改变等错误,产生文档的副作用。为了控制因修改而引起的副作用,应该:按模块把修改分组;自顶向下的安排被修改模块的顺序;每次修改一个模块。,3、软件维护的困难读懂别人的程序困难。文档的不一致性。软件开发人员和软件维护人员在时间上的差异。软件维护工作是一项难出成果的工作。结构化维护 指软件开发过程是按照软件工程方法进行的,开发各阶段文档齐全,软件的维护过程,有一整套完整的方案、技术、审定过程。非结构化维护 只有源程序,缺乏必要的文档说明,难于确定数据结构、系统接口等特性。维护工作令人生畏,事倍功半。,9.1.4 软件维护的工作量及模型,1.软件维护的工作量 软件维护的费用在整个软

6、件开发费用的55%-70%,并且所占比例在逐年上升。而且维护中还可能产生新的潜在错误。例如1970 年维护费用约占软件开发费用的40%,到1990年维护费用所占比例就超过了70%。另外维护还包含了无形的资源占用,包括大量的使用很多硬件、软件和软件工程师等资源。在软件维护时,直接影响维护成本和工作量的因素很多,主要如下:(1)系统规模大小 系统规模大小直接影响维护工作量,系统规模越大,仅仅看懂理解就很困难,维护的工作量就更多。系统规模主要由源代码行数、程序模块数、数据接口文件数、使用数据库规模大小等因素衡量。,9.1.4 软件维护的工作量及模型,1.软件维护的工作量(2)程序设计语言 解决相同的

7、问题选择不同的程序设计语言,得到的程序的规模可能不同。(3)系统使用年限 使用年限长的老系统维护比新系统所需要的工作量更多。(4)软件开发新技术的应用 软件开发过程中,使用先进的分析和设计技术,以及程序设计技术,如:面向对象的技术、构件技术、可视化程序设计技术等,可以减少维护工作量。(5)设计过程中的技术 在具体对软件进行维护时,影响维护工作量的其他因素还有很多,例如设计过程中应用的类型、数学模型、任务的难度、开关与标记、IF 嵌套深度、索引或下标数等。,9.1.4 软件维护的工作量及模型,2.软件维护工作量模型 维护活动分为生产性活动和非生产性活动。生产性活动包括分析评价、修改设计和编写程序

8、代码等。非生产性活动包括理解程序代码,解释数据结构,接口特点和设计约束等。Belady 和Lehman 提出软件维护工作模型:M=P+K*EXP(C-D)其中:M维护总工作量P生产性活动K经验常数C程序复杂度(由非结构化维护引起的)D对维护软件熟悉程度的度量。上式可以发现,C 越大,D 越小,那么维护工作量就成指数的增加。C 增加主要因为软件采用非结构化设计,程序复杂性高;D 减小表示维护人员不是原来的开发人员,不熟悉程序,理解程序花费太多时间。,二、软件维护的代价,维护费用高达开发费用的55%70%,而且逐年上涨。维护中还可能引入新的潜在错误。Belady 和 Lehman 提出软件维护工作

9、模型:M=P+K*EXP(C-D)其中:M维护总工作量P生产性活动K经验常数C程序复杂度(由非结构化维护引起的)D对维护软件熟悉程度的度量。,结论,9.2 软件维护的过程,1.维护组织 除大的软件公司外,通常的在软件维护工作方面,并不保持一个正式的组织。在软件开发部门,确立一个非正式的维护组织即非正式的维护管理员来负责维护工作却是绝对必要的。,2、维护工作的流程,用户,维护人员,安排改正性维护,确认维护类型,维护实施,评价优先级,进行问题分析,复审,评价错误严重程度,进行问题分析,确定更改要求,维护要求,完 美 性,适 应 性,将安排好的工作量列入计划,低,高,纠错性,严重,不严重,将改正错误

10、列入计划,人 员 安排,人 员 安 排,交付使用的软件,理解分析程序,安排计划修改程序,测试程序,或,或,或,或,软件维护的工作流程图,修改过的软件,3、维护工作的组织管理,软件维护工作不仅是技术性的,它还需要大量的管理工作与之相配合,才能保证维护工作的质量。管理部门应对提交的修改方案进行分析和审查,并对修改带来的影响作充分的估计,对于不妥的修改予以撤销。需修改主文档时,管理部门更应仔细审查。软件维护的管理流程如图所示:,软件维护的管理流程,维护修改建议,分析修改建议,是否合理,提交管理部门审查,是否同意,修改,撤销,N,Y,N,Y,进行测试,提交管理部门审批,是否批准,更新主文档,Y,更新其

11、他文档,提交使用,修改,N,一、结构化维护与非结构化维护结构化维护 指软件开发过程是按照软件工程方法,软件的维护过程,有一整套完整的方案、技术、审定过程。非结构化维护 缺乏必要的文档说明,难于确定数据结构、系统接口等特性。维护工作令人生畏,事倍功半。,二、软件维护的代价,维护费用高达开发费用的55%70%,而且逐年上涨。维护中还可能引入新的潜在错误。Belady 和 Lehman 提出软件维护工作模型:M=P+K*EXP(C-D)其中:M维护总工作量P生产性活动K经验常数C程序复杂度(由非结构化维护引起的)D对维护软件熟悉程度的度量。,结论,9.3 软件维护的技术,在软件开发阶段用来减少错误,

12、提高软件可维护性的技术。涉及到软件开发的所有阶段。,可维护性(可测试性、可理解性、可修改性),二、软件支援技术,一、面向维护的技术,在软件维护阶段用于提高维护工作的效率和质量的技术。主要用到测试阶段的技术。,(信息收集、错误原因分析、软件分析与理解、维护方案评价、代码与文档的修改、修改后的确认。),维护支援技术是在软件维护阶段用来提高维护作业的效率和质量的技术。包括:1.信息收集:收集有关系统在运行过程中的各种问题。2.错误原因分析:分析所收集到的信息,分析出错的原因。3.软件分析与理解:只有对需要维护的软件进行认真的理解,才保证软件维护正确进行。4.维护方案评价:在进行维护修改前,要确定维护

13、方案,并由相关的组织进行评审通过后才能执行。5.代码与文档修改:实施维护方案。6.修改后的确认:经过修改的软件,需要重新进行测试。7.远距离的维护:对于网络系统,可以通过远程控制进行维护。,三、维护档案记录,为了更好地做好软件维护工作,包括估计维护的有效程度,确定软件产品的质量,确定维护的实际开销等,应该在维护的过程中记录好维护全过程,建立维护档案。四、维护工作评价 对于维护工作地评价一般较为困难,因为很多时候没有量化的数据,但可记录维护性能地度量值,这些度量值一般有:记录维护申请报告的平均处理时间;统计每类维护上的总“人时”数的开销;统计每次程序运行时的平均出错次数;统计在维护中,增删每个源

14、程序语句所花费的平均“人时”数;记录每段程序、每种语言、每种维护类型的程序平均修改次数;统计所用语言及用于每种语言的平均“人时”数计算各类维护申请的百分比;这些度量值提供的是定量数据,可以评价维护工作。,9.4 软件可维护性,许多软件的维护很困难,主要因为软件的源程序和文档难于理解和修改。由于维护工作面广,维护的难度大,稍有不慎,就会在修改中给软件带来新的问题或引入新的错误,所以为了使得软件能够易于维护,必须考虑使软件具有可维护性。9.4.1 软件可维护性的定义 软件可维护性是指软件能够被理解,并能纠正软件系统出现的错误和缺陷,以及为满足新的要求进行修改、扩充或压缩的容易程度。软件的可维护性、

15、可使用性和可靠性是衡量软件质量的几个主要特性,也是用户最关心的问题之一。但影响软件质量的这些因素,目前还没有普遍适用的定量度量的方法。,软件维护可用如下的七个质量特性来衡量,即可理解性、可测试性、可修改性、可靠性、可移植性、可使用性和效率。而且对于不同类型的维护,这七种特性的侧重点也不相同。目前广泛使用的衡量程序的可维护性的七种特性如表所示。,9.4.2 可维护性的度量,由于许多质量特性是相互抵触的,要考虑几种不同的度量标准,去度量不同的质量特性。1.可理解性 一个可理解的软件主要应该具备的特性是:模块化,风格一致性,使用清晰明确的代码,使用有意义的数据名和过程名,结构化,完整性等。对于可理解

16、性,Shneiderman 提出一种叫做“90-10 测试法”来衡量。即让有经验的程序员阅读10 分钟要测试的程序,然后如能凭记忆和理解写出90的程序,则称该程序是可理解的。,2.可靠性 可靠性表明一个软件按照用户的要求和设计目标,在给定的一段时间内正确执行的概率。可靠性的主要度量标准有:平均失效间隔时间、平均修复时间、有效性。度量可靠性的方法,主要有两类:(1)根据软件错误统计数字,进行可靠性预测。(2)根据软件复杂性,预测软件可靠性。3.可测试性 可测试性表明论证软件正确性的容易程度。对于软件中的程序模块,可用程序复杂性来度量可测试性。明显地,程序的环路复杂性越大,程序的路径就越多,全面测

17、试程序的难度就越大。,4.可修改性 测试可修改性的一种定量方法是修改练习。基本思想是通过做几个简单的修改,来评价修改难度。设C 是程序中各个模块的平均复杂性,n 是必须修改的模块数,A 是要修改的模块的平均复杂性。则修改的难度表示为:D=A/C在简单修改时当D1,说明该软件修改困难。A 和C 可用任何一种度量程序复杂性的方法计算。5.可移植性 表明软件转移到一个新的计算环境的可能性的大小。或者软件能有效地在各种环境中运行的容易程度。一个可移植性好的软件应具有良好、灵活、不依赖于某一具体计算机或操作系统的性能。6.效率 效率表明一个软件能执行预定功能而又不浪费机器资源的程度。包括:内存容量、外存

18、容量、通道容量和执行时间。7.可使用性 从用户的角度出发,可使用性是软件方便、实用、及易于使用的程度。一个可使用的程序应该易于使用、允许出错和修改,而且尽量保证用户在使用时不陷入混乱状态。,9.4.3 提高可维护性的方法,软件的可维护性对于延长软件的生存期具有决定意义,因此必须考虑怎样才能提高软件的可维护性。为此,可从以下五个方面着手。1.建立明确的软件质量目标2.使用先进的软件开发技术和工具 利用先进的软件开发技术是软件开发过程中提高软件质量,降低成本的有效方法之一,也是提高可维护性的有效的技术。常用的技术有:模块化、结构化程序设计,自动重建结构和重新格式化的工具等。例如,面向对象的软件开发

19、方法就是一个非常使用而强有力的软件开发方法。3.建立明确的质量保证工作 质量保证是提高软件质量所做的各种检查工作。在软件开发和软件维护的各阶段,质量保证检查是非常有效的方法。为了保证软件的可维护性,有四种类型的软件检查:(1)在检查点进行复审,软件开发期间各个检查点的检查重点,各阶段的重点、对象和方法,4.选择可维护的程序设计语言,5.改进程序的文档,(1)程序文档(2)用户文档(3)操作文档(4)数据文档(5)历史文档,9.5 逆向工程和再工程,需要对旧的软件进行重新处理、调整,提高其可维护性,这种活动称为“软件再工程”,是提高软件可维护性的一类重要的软件工程活动。再工程也称复壮(修理)或再

20、生。它不仅能从已存在的程序中重新获得设计信息,而且还能使用这些信息来改建或重构现有的系统,以改善它的综合质量。一般软件人员利用再工程重新实现已存在的程序,同时加进新的功能或改善它的性能。9.5.1 逆向工程 软件的逆向工程是分析程序,力图在比源代码更高抽象层次上建立程序表示的过程;是一个设计恢复的过程。使用逆向工程工具可以从已经存在的软件中提取数据结构、体系结构和程序设计结构。逆向工程的过程如图所示。,逆向工程的过程从源代码重构开始,将无结构的源代码转换为结构化的源代码,提高了源代码的易读性。抽取是逆向工程的核心,内容包括处理抽取、界面抽取和数据抽取。处理抽取可在不同层次进行;如语句段、模块、

21、子系统、系统。使用逆向工程工具,可以从已存在程序中抽取数据结构、体系结构和程序设计信息。,9.5.2 软件重构,软件重构是对源代码、数据进行修改,使其易于修改和维护,以适应将来的变更。通常软件重构并不修改软件体系结构,而是关注模块的细节。1、代码重构 代码重构的目标是生成可提供功能相同,而质量更高的程序。2、数据重构 发生在较低的抽象层次上,是一种全局的再工程活动。数据重构通常以逆向工程活动开始,理解现存的数据结构,又称数据分析,再重新设计数据,包括数据标准化、数据命名合理、文件格式转换、数据库格式转换等。3、软件重构的意义 提高软件质量和生产率,减少维护工作量,提高软件可维护性。,9.5.3

22、 再工程的成本/效益分析,再工程要耗费时间,占用资源。为了降低再工程的风险,必须进行成本效益分析。Sneed 提出了再工程的成本效益模型:1.与未执行再工程的持续维护相关的成本:,2.与再工程相关的成本:,3.再工程的整体收益:,其中:p1:当前某应用的年维护成本;p2:当前某应用的年运行成本;p3:当前某应用的年收益;p4:再工程后预期年维护成本;p5:再工程后预期年运行成本;p6:再工程后预期业务收益;p7:估计的再工程成本;p8:估计的再工程日程;p9:再工程的风险因子(=1.0)L:期望的系统生命期(年),9.5.4 再工程的风险分析,再工程的风险主要有以下几个方面:.过程风险:在进行再工程活动中,缺乏对投入人员的管理;及对再工程方案的实施缺乏管理,未作成本效益分析。.应用领域风险:对再工程项目中的业务知识不熟悉,缺少专业 领域的专家支持。.技术风险:缺乏再工程技术支持,恢复设计得到的信息无用等。4.人员风险,工具风险等。软件再工程是提高软件可维护性的一类重要的软件工程活动。与软件开发相比,软件再工程不是从编写规格说明开始,而是从原有的软件出发,通过再工程,获得可维护性好的新软件。,

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 生活休闲 > 在线阅读


备案号:宁ICP备20000045号-2

经营许可证:宁B2-20210002

宁公网安备 64010402000987号