《软件工程第15章34190.pptx》由会员分享，可在线阅读，更多相关《软件工程第15章34190.pptx（32页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、课程名称：软件工程课程名称：软件工程 第第25讲讲班班 级：级：日日 期：期：教教 室：室：教学题目：第教学题目：第15章章 软件维护软件维护教学目的：了解维护的概念，掌握四类维护，教学目的：了解维护的概念，掌握四类维护，了解维护过程、软件的可维护性。了解维护过程、软件的可维护性。教学重点：维护的概念、维护过程、可维护性。教学重点：维护的概念、维护过程、可维护性。教学难点：维护过程。教学难点：维护过程。教教 具：多媒体教室、电子教案具：多媒体教室、电子教案作作 业：业：第第15章章软件维护软件维护软件维护是软件生命周期的最后一个阶段，软软件维护是软件生命周期的最后一个阶段，软件从部署完毕到退役
2、的整个时间内对软件的改件从部署完毕到退役的整个时间内对软件的改动所做的工作都是维护的内容。动所做的工作都是维护的内容。在项目的各个阶段对项目的可维护性进行充分在项目的各个阶段对项目的可维护性进行充分考虑、对可维护性的严格评审以及在维护阶段考虑、对可维护性的严格评审以及在维护阶段有效地组织和管理维护活动，则是保证软件可有效地组织和管理维护活动，则是保证软件可维护性和降低维护费用的关键。维护性和降低维护费用的关键。本章重点内容：维护的主要内容、维护的流程、本章重点内容：维护的主要内容、维护的流程、如何在软件的生产过程各个阶段保证软件的可如何在软件的生产过程各个阶段保证软件的可维护性目标。维护性目标
3、。15.1 软件维护的基本内容软件维护的基本内容软件维护的主要目标是使已部署的软件软件维护的主要目标是使已部署的软件按照需求规格说明书的要求（或用户的按照需求规格说明书的要求（或用户的新需求）运行，这要求软件不仅要满足新需求）运行，这要求软件不仅要满足用户所需要的各项功能需求，同时还要用户所需要的各项功能需求，同时还要满足用户对软件的非功能需求。软件维满足用户对软件的非功能需求。软件维护的基本内容则包含了实现这些目标所护的基本内容则包含了实现这些目标所做的全部工作。做的全部工作。15.2 软件维护的分类软件维护的分类q按照维护的起因分类：按照维护的起因分类：纠错性维护纠错性维护 适应性维护适应
4、性维护 改善性维护改善性维护 预防性维护四类。预防性维护四类。1.纠错性维护纠错性维护为改正软件系统中潜藏为改正软件系统中潜藏 的错误而进行的活动。的错误而进行的活动。用户在使用软件过程中发现软件的错误用户在使用软件过程中发现软件的错误是激发该种维护的起因。是激发该种维护的起因。四类四类15.2 软件维护的分类软件维护的分类2.适应性维护适应性维护为适应软件运行环境的为适应软件运行环境的 变化而修改软件的活动。变化而修改软件的活动。软件的运行环境包括两个方面，硬件和软件的运行环境包括两个方面，硬件和软件，软件则大体上包括操作系统、中软件，软件则大体上包括操作系统、中间件、虚拟机等等。间件、虚拟
5、机等等。15.2 软件维护的分类软件维护的分类3.改善性维护改善性维护根据用户在软件使用过根据用户在软件使用过程中提出的建设性意见而进行的维护活程中提出的建设性意见而进行的维护活动。动。主要是针对用户提出的新的软件需求或主要是针对用户提出的新的软件需求或修改原有的软件需求而进行的维护，该修改原有的软件需求而进行的维护，该种维护通常占所有维护工作量的一半以种维护通常占所有维护工作量的一半以上。软件在部署之后一段时间内，用户上。软件在部署之后一段时间内，用户的改善性维护应该是递减的。的改善性维护应该是递减的。15.2 软件维护的分类软件维护的分类4.预防性维护预防性维护为了进一步改善软件系为了进一
6、步改善软件系统的可维护性和可靠性，并为以后的改统的可维护性和可靠性，并为以后的改进奠定基础。进奠定基础。预防性维护可以采取逆向工程（预防性维护可以采取逆向工程（reverse engineering）和重构工程（）和重构工程（re-engineering）方式。）方式。15.2 软件维护的分类软件维护的分类严格按照软件工程标准生产的软件产品严格按照软件工程标准生产的软件产品在维护过程中纠错性维护的工作量很低，在维护过程中纠错性维护的工作量很低，不到总维护工作量的不到总维护工作量的15。由于改善性维护和适应性维护需要修改由于改善性维护和适应性维护需要修改需求规格说明书，应按照需求变更来进需求规格
7、说明书，应按照需求变更来进行管理，相当于螺旋模型中的又一次迭行管理，相当于螺旋模型中的又一次迭代过程，因此工作量很大。代过程，因此工作量很大。15.3 软件维护的特点软件维护的特点软件维护是一种繁琐而又不可或缺软件维护是一种繁琐而又不可或缺的工作，由于维护通常要求维护人的工作，由于维护通常要求维护人员在用户现场进行，而且维护任务员在用户现场进行，而且维护任务可能非常紧急，因此对现场维护人可能非常紧急，因此对现场维护人员的压力很大。而且没有丝毫的成员的压力很大。而且没有丝毫的成就感。就感。15.3.1 结构化维护与非结构化维护结构化维护与非结构化维护非结构化维护非结构化维护软件的配置中只有源软件
8、的配置中只有源代码。代码。由于没有分析和设计文档，无法对程序由于没有分析和设计文档，无法对程序的功能进行反向追踪，理解别人的代码的功能进行反向追踪，理解别人的代码是很痛苦的事情。是很痛苦的事情。由于配置中没有测试文档，所以维护后由于配置中没有测试文档，所以维护后的代码无法进行回归测试。因而导致程的代码无法进行回归测试。因而导致程序的结构化被不断的破坏，维护的质量序的结构化被不断的破坏，维护的质量无法得到保证。无法得到保证。15.3.1 结构化维护与非结构化维护结构化维护与非结构化维护结构化维护结构化维护待维护的软件的配置是待维护的软件的配置是完整的。完整的。用户提出的维护申请用正向追踪很容易用
9、户提出的维护申请用正向追踪很容易从分析设计文档追踪直至代码中，从而从分析设计文档追踪直至代码中，从而使维护人员很容易定位代码的维护点。使维护人员很容易定位代码的维护点。所以这种维护不会破坏软件的结构。所以这种维护不会破坏软件的结构。结构化维护不仅能减少维护的工作量，结构化维护不仅能减少维护的工作量，还能提高维护的质量。还能提高维护的质量。图图15-3-1 非结构化维护和结构化维护非结构化维护和结构化维护维护请求维护请求配置配置理解代码功能理解代码功能理解理解？修改代码修改代码测试复审测试复审理解设计理解设计方案规划方案规划修改设计修改设计修改代码修改代码测试复审测试复审交付使用交付使用软件软件
10、代码代码15.3.2 维护成本维护成本20世纪世纪70年代，软件的维护费用约占软年代，软件的维护费用约占软件总预算的件总预算的3540%。80年代时，软件维护费用进一步增加，年代时，软件维护费用进一步增加，约占软件总预算的约占软件总预算的60%。近年来，该值已上升到近年来，该值已上升到80%左右。左右。随着软件复杂性的不断提高，软件的维随着软件复杂性的不断提高，软件的维护难度越来越大。这不仅导致维护成本护难度越来越大。这不仅导致维护成本不断增高，软件生产率急剧下降，还会不断增高，软件生产率急剧下降，还会带来其他方面的负面影响。带来其他方面的负面影响。维护工作量的估算模型维护工作量的估算模型 M
11、P+Ke(c-d)其中：其中：M：维护所用工作量；：维护所用工作量；P：生产性工作量：生产性工作量 分析评价、修改设计和代码；分析评价、修改设计和代码；Ke(c-d)：助动性工作量：助动性工作量 理解文档和代码；理解文档和代码；K：经验常数；：经验常数；c：软件的维护复杂度，由软件本身的复杂度，软：软件的维护复杂度，由软件本身的复杂度，软 件的设计质量以及文档化的程度等因素决定；件的设计质量以及文档化的程度等因素决定；d：维护人员对软件的熟悉程度；：维护人员对软件的熟悉程度；可见维护工作量同软件的维护复杂度成指数关系。可见维护工作量同软件的维护复杂度成指数关系。15.3.3 维护可能存在的问题
12、维护可能存在的问题1）无法追踪软件的整个创建过程。）无法追踪软件的整个创建过程。2）无法追踪软件版本的进化过程。）无法追踪软件版本的进化过程。软件交付使用后对软件不断修复和完善的软件交付使用后对软件不断修复和完善的 过程，就是软件版本的进化过程，每一次过程，就是软件版本的进化过程，每一次 进化都会使软件的主、次版本号增大。进化都会使软件的主、次版本号增大。3）理解别人的程序非常困难。）理解别人的程序非常困难。4）得不到开发人员的帮助。）得不到开发人员的帮助。5）软件配置不完整或不正确。）软件配置不完整或不正确。6）分析和设计的缺陷。）分析和设计的缺陷。7）维护工作让人没有成就感。）维护工作让人
13、没有成就感。15.4 软件维护过程软件维护过程 15.4.1 维护组织维护组织 维护组织一般由维护员，维护管理员，系统管维护组织一般由维护员，维护管理员，系统管理员，修改控制决策机构，配置管理员组成。理员，修改控制决策机构，配置管理员组成。维护员维护员真正执行维护的人员；真正执行维护的人员；维护管理员维护管理员协调维护活动的人员；协调维护活动的人员；系统管理员系统管理员系统的管理者；系统的管理者；修改控制决策机构修改控制决策机构决定一次维护的走向。决定一次维护的走向。修改控制和决策机构、用户、系统管理员、维修改控制和决策机构、用户、系统管理员、维护人员之间不能跨越维护管理员进行沟通和采护人员之
14、间不能跨越维护管理员进行沟通和采取行动。取行动。图图15-4-1 维护组织信息流图维护组织信息流图修改控制决策机构修改控制决策机构系统系统管理员管理员维护维护管理员管理员维护员维护员配置配置管理员管理员维护申请单维护申请单维护流程维护流程用户的维护请求激发了一次维护活动，用户用户的维护请求激发了一次维护活动，用户将维护申请提交给维护管理员，维护管理员将维护申请提交给维护管理员，维护管理员将该维护请求交给系统管理员对维护活动可将该维护请求交给系统管理员对维护活动可能引起的软件修改进行评估，并将评估结果能引起的软件修改进行评估，并将评估结果反馈给维护管理员，维护管理员按照维护请反馈给维护管理员，维
15、护管理员按照维护请求单制定软件修改报告单并提交给修改决策求单制定软件修改报告单并提交给修改决策机构进行维护决策。修改决策机构根据情况机构进行维护决策。修改决策机构根据情况决定采取的行动（拒绝请求还是接收请求），决定采取的行动（拒绝请求还是接收请求），并把结果反馈给维护管理员，如果允许维护，并把结果反馈给维护管理员，如果允许维护，维护管理员将通知维护员执行该次维护。维护管理员将通知维护员执行该次维护。15.4.2 维护的报告与审核维护的报告与审核用户提出的维护申请必须采用标准的格式，须填写由用户提出的维护申请必须采用标准的格式，须填写由维护人员制定的：维护人员制定的：维护申请单（维护申请单（Ma
16、intenance Request Form，MRF）或或 软件问题报告单（软件问题报告单（Software Problem Report，SPR）。）。如果是纠错性维护，应填写如果是纠错性维护，应填写SPR。在填写。在填写SPR时，用时，用户必须完整地记录出错信息（什么错误）和出错场景户必须完整地记录出错信息（什么错误）和出错场景（在什么情况下出现的错误）。（在什么情况下出现的错误）。其他种类的维护，要填其他种类的维护，要填MRF。在。在MRF中应该附加简中应该附加简短的修改规格说明，也就是在需求规格说明书中应作短的修改规格说明，也就是在需求规格说明书中应作哪些改动，比如增加功能或修改功能等
17、。哪些改动，比如增加功能或修改功能等。15.4.2 维护的报告与审核维护的报告与审核维维护护管管理理员员将将MRF后后之之提提交交给给系系统统管管理理员员，并并据据此此对对软软件件改改动动量量作作评评估估。系系统统管管理理员员核核准准该该维维护护申申请请后后，维维护护组组织织内内部部要要制制定定一一个个软软件件修修改改报报告告单单（Software Change Report，SCR），MRF并并不不是是软软件件文文档档的的配配置项。而软件修改的真正依据是置项。而软件修改的真正依据是SCR，其内容如下：，其内容如下：1）本次修改所需工作量；）本次修改所需工作量；2）本次维护活动的性质；）本次维
18、护活动的性质；3）本次维护请求的优先级；）本次维护请求的优先级；4）本次修改的背景数据（来自于）本次修改的背景数据（来自于MRF或或SPR的陈述）。的陈述）。将将SCR提提交交给给修修改改控控制制决决策策机机构构，作作为为维维护护进进一一步步工工作作的的依依据据。SCR是是保保证证软软件件版版本本进进化化可可跟跟踪踪性性所所必必须须的文档。的文档。15.4.3 维护过程的事件流维护过程的事件流用户的维护请求提交给维护组织后的信用户的维护请求提交给维护组织后的信息流程如图息流程如图15-4-2所示。收到维护请求后，所示。收到维护请求后，维护组织首先要判断维护的类型，即本维护组织首先要判断维护的类
19、型，即本次维护请求是纠错性维护还是其他类型次维护请求是纠错性维护还是其他类型的维护。对于纠错维护要启动纠错维护的维护。对于纠错维护要启动纠错维护流程，如果是其他类型的维护则启动适流程，如果是其他类型的维护则启动适应性或改善性维护流程。用户和维护组应性或改善性维护流程。用户和维护组织有时会对维护的类型有不同的看法。织有时会对维护的类型有不同的看法。图图15-4-2 维护活动的事件流维护活动的事件流其他其他出错出错维护请求维护请求类型类型“救火活动救火活动”当排在队列之首当排在队列之首严重性严重性按按SE方法学规划、组织、实施工程方法学规划、组织、实施工程队列中还有维护请求队列中还有维护请求评估后
20、分类评估后分类评估后按优先级评估后按优先级在对列排队在对列排队通知请求者通知请求者并说明原因并说明原因资源用于开发新的软件资源用于开发新的软件采取行动采取行动从维护请求队列之首取一任务从维护请求队列之首取一任务类型类型按优先级在对列按优先级在对列中排队中排队评估后按优先级在队评估后按优先级在队列排队列排队是是否否适应性适应性改善性改善性非常严重非常严重并不严重并不严重是是否否15.4.4 保存维护记录保存维护记录为为了了能能够够很很好好地地评评价价维维护护的的有有效效性性，必必须须详详细细记记录录软软件件维维护护过过程程中中的的各各种种数数据据，这这些些数数据据包包括：括：（1）程序标志；）程
21、序标志；（2）源程序行数；）源程序行数；（3）目标程序的指令条数；）目标程序的指令条数；（4）所用的编程语言；）所用的编程语言；（5）安装程序的日期；）安装程序的日期；（6）自安装之日起程序运行的次数；）自安装之日起程序运行的次数；（7）自安装之日起程序失败的次数；）自安装之日起程序失败的次数；（8）程序修改处的层数和标志；）程序修改处的层数和标志；15.4.4 保存维护记录保存维护记录（9）因程序变动而增加和删除的源程序行数；）因程序变动而增加和删除的源程序行数；（10）每处改动所耗费的人时数；）每处改动所耗费的人时数；（11）程序改动的日期；）程序改动的日期；（12）软件工程师标志；）软件
22、工程师标志；（13）MRF的标志；的标志；（14）本次维护的类型；）本次维护的类型；（15）维护开始和结束的日期；）维护开始和结束的日期；（16）用于本次维护累计的人时数；）用于本次维护累计的人时数；（17）执行本次维护的纯利润。）执行本次维护的纯利润。上述数据应保存到维护数据库里，作为维护评上述数据应保存到维护数据库里，作为维护评价的依据。价的依据。15.4.5 评价维护活动评价维护活动通通过过每每次次维维护护活活动动的的详详细细记记录录，可可通通过过下下面面的的指标度量维护的有效性：指标度量维护的有效性：（1）程序运行的平均失效次数（失效次数运）程序运行的平均失效次数（失效次数运 行的次数
23、）；行的次数）；（2）维护活动耗费的总人时数；）维护活动耗费的总人时数；（3）各种程序，及各种语言的平均变动数；）各种程序，及各种语言的平均变动数；（4）维护阶段修改每条语句所花费的人时数；）维护阶段修改每条语句所花费的人时数；（5）维护每种语言的程序平均花费的人时数；）维护每种语言的程序平均花费的人时数；（6）一张）一张MRF的平均周转时间；的平均周转时间；（7）各类维护请求的百分比。）各类维护请求的百分比。15.5 维护的副作用维护的副作用维护的副作用是指，由于维护或在维护过程中维护的副作用是指，由于维护或在维护过程中其他一些不期望的行为引入的错误。副作用可其他一些不期望的行为引入的错误。
24、副作用可分三类：分三类：（1）代码副作用）代码副作用下面的修改最易引起副作用：下面的修改最易引起副作用：修改或删除子程序；修改或删除子程序；修改或删除语句标号；修改或删除语句标号；修改或删除标识符；修改或删除标识符；为提高程序效率而做的修改；为提高程序效率而做的修改；修改逻辑操作符；修改逻辑操作符；由设计变动引起的代码修改；由设计变动引起的代码修改；修改分支处的判断条件；修改分支处的判断条件；代码副作用大多数可在回归测试中发现。代码副作用大多数可在回归测试中发现。15.5 维护的副作用维护的副作用（2）数据副作用）数据副作用数数据据副副作作用用是是由由于于修修改改数数据据结结构构带带来来的的副
25、副作作用用。容易引起数据副作用的修改包括：容易引起数据副作用的修改包括：局部和全局常量的再定义；局部和全局常量的再定义；记录或文件格式的再定义；记录或文件格式的再定义；增减数据或是由于修改数据结构的定义导致增减数据或是由于修改数据结构的定义导致 数据结构长度的改变；数据结构长度的改变；修改全局数据；修改全局数据；重新初始化控制标志和指针；重新初始化控制标志和指针；重新排列重新排列I/O表或子程序参数表。表或子程序参数表。设设计计文文档档化化有有助助于于抑抑制制数数据据副副作作用用，在在设设计计文文档中有关于数据结构的详细描述和交叉访问表。档中有关于数据结构的详细描述和交叉访问表。15.5 维护
26、的副作用维护的副作用（3）文档副作用）文档副作用由于程序修改而没有对文档进行相应的由于程序修改而没有对文档进行相应的修改引起文档的副作用。修改引起文档的副作用。必须保持文档和程序的一致性。每次维必须保持文档和程序的一致性。每次维护之后，再次交付软件之前应仔细评审护之后，再次交付软件之前应仔细评审整个配置，这样才能更好地减少文档的整个配置，这样才能更好地减少文档的副作用。副作用。15.6 软件的可维护性软件的可维护性软件的可维护性是指软件被理解和被正软件的可维护性是指软件被理解和被正确改动的难易程度。确改动的难易程度。软件的可维护性差是软件维护工作量和软件的可维护性差是软件维护工作量和费用激增的
27、直接原因，因此在软件工程费用激增的直接原因，因此在软件工程的各个阶段都要保证软件具有较高可维的各个阶段都要保证软件具有较高可维护性，从而降低软件维护成本，这是软护性，从而降低软件维护成本，这是软件工程的重要目标之一。件工程的重要目标之一。15.6.1 影响可维护性的因素影响可维护性的因素软件的可维护性主要受下面因素影响：软件的可维护性主要受下面因素影响：（1）软件的构造过程是否严格按照软件工）软件的构造过程是否严格按照软件工 程的方法进行；程的方法进行；（2）开发团队是否训练有素；）开发团队是否训练有素；（3）软件的开发平台（操作系统和开发语）软件的开发平台（操作系统和开发语 言）是否标准。言
28、）是否标准。总总结结起起来来就就是是：开开发发团团队队（人人）是是否否使使用用了了通通用用的的工工具具采采用用标标准准的的方方法法来来构构造造软件。软件。15.6.2 可维护性的度量可维护性的度量通过维护记录可间接度量可维护性。通过维护记录可间接度量可维护性。（1）问问题题、收收集集维维护护工工具具以以及及分分析析问问题题所所用的时间；用的时间；（2）形成修改说明书所用的时间；）形成修改说明书所用的时间；（3）修改设计和源代码所用的时间；）修改设计和源代码所用的时间；（4）测试所用时间；）测试所用时间；（5）复审所用时间；）复审所用时间；（6）完全恢复所用时间。）完全恢复所用时间。以上时间越短
29、则软件的可维护性越好。以上时间越短则软件的可维护性越好。15.6.3 可维护性复审可维护性复审在软件工程每一阶段的复审中，可维护性都是在软件工程每一阶段的复审中，可维护性都是一个重要的指标。一个重要的指标。在需求分析阶段的复审中，应在规格说明书中在需求分析阶段的复审中，应在规格说明书中对将来可能修改和可以改进的部分加以注明；对将来可能修改和可以改进的部分加以注明；在设计阶段的复审中，应该从易于维护和提高在设计阶段的复审中，应该从易于维护和提高设计总体质量的角度对设计进行全面评审；设计总体质量的角度对设计进行全面评审；代码复审主要审查代码风格和内部文档（程序代码复审主要审查代码风格和内部文档（程序注释等）这两个直接影响可维护性的因素。注释等）这两个直接影响可维护性的因素。最后，每一阶段性测试，直到软件正式交付之最后，每一阶段性测试，直到软件正式交付之前，都应该进行的预防性维护。前，都应该进行的预防性维护。正式的可维护性复审放在测试完成之后，称为正式的可维护性复审放在测试完成之后，称为配置复审。目的是保证配置中所有成分的完整、配置复审。目的是保证配置中所有成分的完整、一致、易于理解且便于修改控制。一致、易于理解且便于修改控制。