软件工程软件维护精.ppt

软件工程软件维护软件工程软件维护第1页，本讲稿共78页q软件维护的概念软件维护的概念q软件维护分类软件维护分类q软件维护活动软件维护活动v结构化维护和非结构化维护结构化维护和非结构化维护v维护成本维护成本v维护可能存在的问题维护可能存在的问题q软件维护过程软件维护过程v维护机构维护机构/组织组织v维护流程维护流程v软件维护文档软件维护文档q维护的副作用维护的副作用q软件的可维护性软件的可维护性q软件维护的新方法软件维护的新方法软件工程软件工程软件维护软件维护 第2页，本讲稿共78页第第15章章软件维护软件维护l软件维护是软件生命周期的最后一个阶段，软件软件维护是软件生命周期的最后一个阶段，软件从部署完毕到退役的整个时间内对软件的改动所从部署完毕到退役的整个时间内对软件的改动所做的工作都是维护的内容。做的工作都是维护的内容。l在项目的各个阶段对项目的可维护性进行充分考虑、在项目的各个阶段对项目的可维护性进行充分考虑、对可维护性的严格评审以及在维护阶段有效地组织和对可维护性的严格评审以及在维护阶段有效地组织和管理维护活动，则是保证软件可维护性和降低维护费管理维护活动，则是保证软件可维护性和降低维护费用的关键。用的关键。l本章重点内容：维护的主要内容、维护的流程、如何本章重点内容：维护的主要内容、维护的流程、如何在软件的生产过程各个阶段保证软件的可维护性目标。在软件的生产过程各个阶段保证软件的可维护性目标。第3页，本讲稿共78页第十五章第十五章 软件维护软件维护l软件后期维护费用有时竟高达软件总费软件后期维护费用有时竟高达软件总费用的用的80%80%，所有前期开发费用仅占，所有前期开发费用仅占20%20%。l许多大型软件公司为维护已有软件耗费大许多大型软件公司为维护已有软件耗费大量人力、财力。因此，必须建立一套评估、量人力、财力。因此，必须建立一套评估、控制和实施软件维护的机制。控制和实施软件维护的机制。第4页，本讲稿共78页软件维护软件维护概念概念是指在软件的运行是指在软件的运行/维护阶段由软件厂维护阶段由软件厂商向客户所提供的服务工作商向客户所提供的服务工作。三层含义三层含义（1 1）软件的维护总是针对某一种软件产品在软）软件的维护总是针对某一种软件产品在软件生存周期内所进行的活动件生存周期内所进行的活动（2 2）当今的软件维护更强调的是服务）当今的软件维护更强调的是服务 。在激烈。在激烈的市场竞争中，同类软件产品的价格、功能、性的市场竞争中，同类软件产品的价格、功能、性能和接口等都差不多，而服务就会成为用户选购能和接口等都差不多，而服务就会成为用户选购软件的重要依据，即软件的重要依据，即“卖软件就是卖服务卖软件就是卖服务”（3 3）软件维护的时间是有限度的，一般而言目前软）软件维护的时间是有限度的，一般而言目前软件产品的免费服务时间为两年左右，两年以后软件厂件产品的免费服务时间为两年左右，两年以后软件厂商总会推出更新的版本以适应用户在功能、性能、接商总会推出更新的版本以适应用户在功能、性能、接口等方面所提出的新需求，从而软件厂商也会找到新口等方面所提出的新需求，从而软件厂商也会找到新的利润增长点。的利润增长点。第5页，本讲稿共78页主讲内容主讲内容l软件维护的分类软件维护的分类l维护活动维护活动l软件维护过程软件维护过程l维护的副作用维护的副作用l软件的可维护性软件的可维护性l软件再工程：逆向工程和重构工程软件再工程：逆向工程和重构工程 第6页，本讲稿共78页15.1 软件维护的分类软件维护的分类q按照维护的起因分类：按照维护的起因分类：纠错性维护纠错性维护 适应性维护适应性维护 改善性维护改善性维护/扩充与完善性维护扩充与完善性维护 预防性维护四类。预防性维护四类。1.纠错性维护纠错性维护（Corrective Maintenance）为改正为改正软件系统中潜藏的错误而进行的活动。软件系统中潜藏的错误而进行的活动。l用户在使用软件过程中发现软件的错误是激发该种用户在使用软件过程中发现软件的错误是激发该种维护的起因。维护的起因。四类四类 第7页，本讲稿共78页15.1 软件维护的分类软件维护的分类2.适应性维护适应性维护（Adaptive Maintenance）为适应软件运行环境的变化而修改软件的为适应软件运行环境的变化而修改软件的活动。活动。软件的运行环境包括两个方面，硬件和软软件的运行环境包括两个方面，硬件和软件，软件则大体上包括操作系统、中间件、件，软件则大体上包括操作系统、中间件、虚拟机等等。虚拟机等等。第8页，本讲稿共78页15.1 软件维护的分类软件维护的分类3.改善性维护改善性维护（Perfective Maintenance）根据用户在软件使用根据用户在软件使用过程中提出的建设性意见而进行的维护过程中提出的建设性意见而进行的维护活动。活动。主要是针对用户提出的新的软件需求或主要是针对用户提出的新的软件需求或修改原有的软件需求而进行的维护，该修改原有的软件需求而进行的维护，该种维护通常占所有维护工作量的一半以种维护通常占所有维护工作量的一半以上。软件在部署之后一段时间内，用户上。软件在部署之后一段时间内，用户的改善性维护应该是递减的。的改善性维护应该是递减的。第9页，本讲稿共78页15.1 软件维护的分类软件维护的分类4.预防性维护预防性维护（Preventive Maintenance）为了进一步改善软件为了进一步改善软件系统的可维护性和可靠性，并为以后的系统的可维护性和可靠性，并为以后的改进奠定基础。改进奠定基础。预防性维护可以采取预防性维护可以采取逆向工程逆向工程（reverse engineering）和）和重构工程重构工程（re-engineering）方式。）方式。第10页，本讲稿共78页15.1 软件维护的分类软件维护的分类l预防性维护即预防性维护即软件再工程软件再工程，是为了提高，是为了提高软件的可维护性、可靠性等，为以后进软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。一步改进软件打下良好基础。预防性维护定义为：采用先进的软件工程方法预防性维护定义为：采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试。进行设计、编制和测试。第11页，本讲稿共78页软件维护的种类软件维护的种类l完善性维护（完善性维护（perfective maintenance）完善和加强产品的功能与性能，以满足用户日益增长的需要。完善和加强产品的功能与性能，以满足用户日益增长的需要。50%l适应性维护（适应性维护（adaptive maintenance）使软件适应运行环境的变化。使软件适应运行环境的变化。25%l纠错性维护（纠错性维护（corrective maintenance）纠正在开发期间未能发现的遗留错误。纠正在开发期间未能发现的遗留错误。21%l预防性维护（预防性维护（preventive maintenance）4%为了进一步改善软件的可靠性和易维护性，或者为将来为了进一步改善软件的可靠性和易维护性，或者为将来的维护奠定更好的基础而对软件进行修改。的维护奠定更好的基础而对软件进行修改。第12页，本讲稿共78页各类维护活动的根本目的是各类维护活动的根本目的是延长软件生存期延长软件生存期其它维护其它维护 4%4%软件软件生存生存周期周期软件诞生软件诞生计计划划分分析析设设计计编编码码测测试试运行和维护运行和维护(简称维护简称维护)改善期改善期 稳定期稳定期 陈旧期陈旧期1 1年年-10-10年年2 2个月个月-2-2年年重构重构软件工程周期软件工程周期15.1 软件维护的分类软件维护的分类 第13页，本讲稿共78页q软件维护的概念软件维护的概念q软件维护分类软件维护分类q软件维护活动软件维护活动v结构化维护和非结构化维护结构化维护和非结构化维护v维护成本维护成本v维护可能存在的问题维护可能存在的问题q软件维护过程软件维护过程v维护机构维护机构/组织组织v维护流程维护流程v软件维护文档软件维护文档q维护的副作用维护的副作用q软件的可维护性软件的可维护性q软件维护的新方法软件维护的新方法软件工程软件工程软件维护软件维护 第14页，本讲稿共78页15.2 软件维护活动软件维护活动软件维护是一种繁琐而又不可或缺的工作，软件维护是一种繁琐而又不可或缺的工作，由于维护通常要求维护人员在用户现场进由于维护通常要求维护人员在用户现场进行，而且维护任务可能非常紧急，因此对行，而且维护任务可能非常紧急，因此对现场维护人员的压力很大。而且没有丝毫现场维护人员的压力很大。而且没有丝毫的成就感。的成就感。第15页，本讲稿共78页15.2.1 结构化维护与非结构化维护结构化维护与非结构化维护l非结构化维护非结构化维护软件的配置中只有源软件的配置中只有源代码。代码。l由于没有分析和设计文档，无法对程序由于没有分析和设计文档，无法对程序的功能进行反向追踪，理解别人的代码的功能进行反向追踪，理解别人的代码是很痛苦的事情。是很痛苦的事情。l由于配置中没有测试文档，所以维护后由于配置中没有测试文档，所以维护后的代码无法进行回归测试。因而导致程的代码无法进行回归测试。因而导致程序的结构化被不断的破坏，维护的质量序的结构化被不断的破坏，维护的质量无法得到保证。无法得到保证。第16页，本讲稿共78页15.2.1 结构化维护与非结构化维护结构化维护与非结构化维护结构化维护结构化维护待维护的软件的配置是待维护的软件的配置是完整的。完整的。用户提出的维护申请用正向追踪很容易用户提出的维护申请用正向追踪很容易从分析设计文档追踪直至代码中，从而从分析设计文档追踪直至代码中，从而使维护人员很容易定位代码的维护点。使维护人员很容易定位代码的维护点。所以这种维护不会破坏软件的结构。所以这种维护不会破坏软件的结构。结构化维护不仅能减少维护的工作量，结构化维护不仅能减少维护的工作量，还能提高维护的质量。还能提高维护的质量。第17页，本讲稿共78页15.2.1 结构化与非结构化的维护结构化与非结构化的维护 第18页，本讲稿共78页15.2.2 维护成本维护成本l20世纪世纪70年代，软件的维护费用约占软年代，软件的维护费用约占软件总预算的件总预算的3540%。l80年代时，软件维护费用进一步增加，年代时，软件维护费用进一步增加，约占软件总预算的约占软件总预算的60%。l近年来，该值已上升到近年来，该值已上升到80%左右。左右。l随着软件复杂性的不断提高，软件的维随着软件复杂性的不断提高，软件的维护难度越来越大。这不仅导致维护成本护难度越来越大。这不仅导致维护成本不断增高，软件生产率急剧下降，还会不断增高，软件生产率急剧下降，还会带来其他方面的负面影响。带来其他方面的负面影响。第19页，本讲稿共78页15.2.2 维护成本维护成本l其他因素也已经引起人们的注意。如：其他因素也已经引起人们的注意。如：由于资源由于资源由于资源由于资源(人力、设备人力、设备人力、设备人力、设备)优先用于维护任务，影响新软件系统的优先用于维护任务，影响新软件系统的优先用于维护任务，影响新软件系统的优先用于维护任务，影响新软件系统的开发，可能会丧失机会；开发，可能会丧失机会；开发，可能会丧失机会；开发，可能会丧失机会；有时还要付出一些无形的代价，如某些貌似合理但实际不能满有时还要付出一些无形的代价，如某些貌似合理但实际不能满有时还要付出一些无形的代价，如某些貌似合理但实际不能满有时还要付出一些无形的代价，如某些貌似合理但实际不能满足的维护请求将引起用户不满足的维护请求将引起用户不满足的维护请求将引起用户不满足的维护请求将引起用户不满;在软件维护过程中引入的潜在错误降低了软件的质量在软件维护过程中引入的潜在错误降低了软件的质量在软件维护过程中引入的潜在错误降低了软件的质量在软件维护过程中引入的潜在错误降低了软件的质量;从开发小组中临时抽调工程师从事维护工作冲击正在进行的从开发小组中临时抽调工程师从事维护工作冲击正在进行的从开发小组中临时抽调工程师从事维护工作冲击正在进行的从开发小组中临时抽调工程师从事维护工作冲击正在进行的开发等等。开发等等。开发等等。开发等等。l最后，维护旧程序使生产率最后，维护旧程序使生产率(按每人月代码按每人月代码行或每人月功能点计算行或每人月功能点计算)大幅度下降。大幅度下降。第20页，本讲稿共78页15.2.2 维护成本维护成本l估算模型估算模型MP+Ke e=(c c-d d)M M :维护工作总工作量维护工作总工作量P P:生产性工作量生产性工作量K K :经验常数经验常数c c:复杂度复杂度d d:对该软件熟悉程度的度量对该软件熟悉程度的度量 第21页，本讲稿共78页15.2.3 维护可能存在的问题维护可能存在的问题1）无法追踪软件的整个创建过程。）无法追踪软件的整个创建过程。2）无法追踪软件版本的进化过程。）无法追踪软件版本的进化过程。软件交付使用后对软件不断修复和完善的软件交付使用后对软件不断修复和完善的 过程，就是软件版本的进化过程，每一次过程，就是软件版本的进化过程，每一次 进化都会使软件的主、次版本号增大。进化都会使软件的主、次版本号增大。3）理解别人的程序非常困难。）理解别人的程序非常困难。4）得不到开发人员的帮助。）得不到开发人员的帮助。5）软件配置不完整或不正确。）软件配置不完整或不正确。6）分析和设计的缺陷。）分析和设计的缺陷。7）维护工作让人没有成就感。）维护工作让人没有成就感。第22页，本讲稿共78页15.2.3 维护可能存在的问题维护可能存在的问题l软件维护中出现的大部分问题都可归咎于软件维护中出现的大部分问题都可归咎于软件规划和开发方法的缺陷。软件规划和开发方法的缺陷。l软件开发时采用急功近利还是放眼未来软件开发时采用急功近利还是放眼未来的态度，对软件维护影响极大。的态度，对软件维护影响极大。l一般说来，软件开发若不严格遵循软件一般说来，软件开发若不严格遵循软件开发标准，软件维护就会遇到许多困难。开发标准，软件维护就会遇到许多困难。第23页，本讲稿共78页15.2.4 影响软件维护工作量的因素影响软件维护工作量的因素l在软件维护中，影响维护工作量的因素主在软件维护中，影响维护工作量的因素主要有以下六种：要有以下六种：系统的大小系统的大小系统规模越大，其功能就越复杂，软件维护的系统规模越大，其功能就越复杂，软件维护的工作量也随之增大。工作量也随之增大。程序设计语言程序设计语言使用功能强大的程序设计语言可以控制程序的使用功能强大的程序设计语言可以控制程序的规模。语言的功能越强，生成程序的模块化和规模。语言的功能越强，生成程序的模块化和结构化程度越高，所需的指令数就越少，程序结构化程度越高，所需的指令数就越少，程序的可读性越好。的可读性越好。To be continue 第24页，本讲稿共78页l系统年龄系统年龄系统使用时间越长，所进行的修改就越多，而多次的修系统使用时间越长，所进行的修改就越多，而多次的修改可能造成系统结构混乱。由于维护人员经常更换，程改可能造成系统结构混乱。由于维护人员经常更换，程序变得越来越难于理解，加之系统开发时文档不齐全，序变得越来越难于理解，加之系统开发时文档不齐全，或在长期的维护过程中文档在许多地方与程序实现不一或在长期的维护过程中文档在许多地方与程序实现不一致，从而使维护变得十分困难。致，从而使维护变得十分困难。l数据库技术的应用数据库技术的应用使用数据库，可以简单而有效地存储、管理系统数据，使用数据库，可以简单而有效地存储、管理系统数据，还可以减少生成用户报表应用软件的维护工作量。还可以减少生成用户报表应用软件的维护工作量。To be continue 15.2.4 影响软件维护工作量的因素影响软件维护工作量的因素第25页，本讲稿共78页l先进的软件开发技术先进的软件开发技术 在软件开发过程中，如果采用先进的分析在软件开发过程中，如果采用先进的分析设计技术和程序设计技术，如面向对象技设计技术和程序设计技术，如面向对象技术、复用技术等，可减少大量的维护工作术、复用技术等，可减少大量的维护工作量。量。l其它一些因素其它一些因素如应用的类型、数学模型、任务的难度、如应用的类型、数学模型、任务的难度、开关与标记、开关与标记、IF嵌套深度、索引或下标数嵌套深度、索引或下标数等，对维护工作量也有影响。等，对维护工作量也有影响。15.2.4 影响软件维护工作量的因素影响软件维护工作量的因素第26页，本讲稿共78页q软件维护的概念软件维护的概念q软件维护分类软件维护分类q软件维护活动软件维护活动v结构化维护和非结构化维护结构化维护和非结构化维护v维护成本维护成本v维护可能存在的问题维护可能存在的问题q软件维护过程软件维护过程v维护机构维护机构/组织组织v维护流程维护流程v软件维护文档软件维护文档q维护的副作用维护的副作用q软件的可维护性软件的可维护性q软件维护的新方法软件维护的新方法软件工程软件工程软件维护软件维护 第27页，本讲稿共78页15.3 软件维护过程软件维护过程l软件维护工作在维护申请提出之前就开始软件维护工作在维护申请提出之前就开始了，它必须是一项有组织有制度的工作，了，它必须是一项有组织有制度的工作，包括：包括：建立维护组织，强制报告和评估的过程；建立维护组织，强制报告和评估的过程；为每个维护申请确定标准化的事件序列；为每个维护申请确定标准化的事件序列；制定保存维护活动记录的制度和有关复审及评制定保存维护活动记录的制度和有关复审及评估的标准。估的标准。l每项软件维护活动的过程是：每项软件维护活动的过程是：维护申请维护申请制定维护计划制定维护计划进行维护活动进行维护活动建建立维护文档立维护文档复审复审/评价维护评价维护 第28页，本讲稿共78页维护维护策略策略为维护工作制订流程为维护工作制订流程 所有维护必须先提交维护申请，所有维护必须先提交维护申请，维护申请必须规范维护申请必须规范 软件维护要有计划软件维护要有计划 在维护过程中需做维护记录在维护过程中需做维护记录 对源程序进行修改对源程序进行修改 软件配置的修改软件配置的修改 15.3 软件维护过程软件维护过程 第29页，本讲稿共78页15.3 软件维护过程软件维护过程 15.3.1 维护机构维护机构/组织组织 l维护组织一般由维护员，维护管理员，系统管理员，维护组织一般由维护员，维护管理员，系统管理员，修改控制决策机构，配置管理员组成。修改控制决策机构，配置管理员组成。维护员维护员真正执行维护的人员；真正执行维护的人员；维护管理员维护管理员协调维护活动的人员；协调维护活动的人员；系统管理员系统管理员系统的管理者；系统的管理者；修改控制决策机构修改控制决策机构决定一次维护的走向。决定一次维护的走向。l修改控制和决策机构、用户、系统管理员、维护人员之间修改控制和决策机构、用户、系统管理员、维护人员之间不能跨越维护管理员进行沟通和采取行动。不能跨越维护管理员进行沟通和采取行动。第30页，本讲稿共78页15.3.1 维护机构维护机构/组织组织 第31页，本讲稿共78页15.3.1 维护机构维护机构/组织组织l除了较大的软件开发公司外，一个软件（产除了较大的软件开发公司外，一个软件（产品）的维护工作，并不需要一定设立一个专品）的维护工作，并不需要一定设立一个专门的维护组织机构。至少，在开发部门建立门的维护组织机构。至少，在开发部门建立一个非正式的维护机构则是非常必要的。一个非正式的维护机构则是非常必要的。l维护需求往往是随机发生的。维护申请提交维护需求往往是随机发生的。维护申请提交给维护管理员，并由系统监督员评价。如果给维护管理员，并由系统监督员评价。如果系统监督员做出需要维护的评价，维护负责系统监督员做出需要维护的评价，维护负责人确定如何进行维护。在维护人员进行维护人确定如何进行维护。在维护人员进行维护的过程中，配置管理员严格把关，控制维护的过程中，配置管理员严格把关，控制维护的范围，对软件配置进行审计。的范围，对软件配置进行审计。第32页，本讲稿共78页15.3.2 维护的报告与审核维护的报告与审核l用户提出的维护申请必须采用标准的格式，须填写由维用户提出的维护申请必须采用标准的格式，须填写由维护人员制定的：护人员制定的：维护申请单（维护申请单（Maintenance Request Form，MRF）或或 软件问题报告单（软件问题报告单（Software Problem Report，SPR）。）。l如果是纠错性维护，应填写如果是纠错性维护，应填写SPR。在填写。在填写SPR时，用户必时，用户必须完整地记录出错信息（什么错误）和出错场景（在什须完整地记录出错信息（什么错误）和出错场景（在什么情况下出现的错误）。么情况下出现的错误）。l其他种类的维护，要填其他种类的维护，要填MRF。在。在MRF中应该附加简短的修中应该附加简短的修改规格说明，也就是在需求规格说明书中应作哪些改动，比改规格说明，也就是在需求规格说明书中应作哪些改动，比如增加功能或修改功能等。如增加功能或修改功能等。第33页，本讲稿共78页15.3.2 维护的报告与审核维护的报告与审核维维护护管管理理员员将将MRF后后之之提提交交给给系系统统管管理理员员，并并据据此此对对软软件件改改动动量量作作评评估估。系系统统管管理理员员核核准准该该维维护护申申请请后后，维维护护组组织织内内部部要要制制定定一一个个软软件件修修改改报报告告单单（Software Change Report，SCR），MRF并并不不是是软软件件文文档档的的配配置置项项。而而软软件件修改的真正依据是修改的真正依据是SCR，其内容如下：，其内容如下：1）本次修改所需工作量；）本次修改所需工作量；2）本次维护活动的性质；）本次维护活动的性质；3）本次维护请求的优先级；）本次维护请求的优先级；4）本次修改的背景数据（来自于）本次修改的背景数据（来自于MRF或或SPR的陈述）。的陈述）。l将将SCR提提交交给给修修改改控控制制决决策策机机构构，作作为为维维护护进进一一步步工工作作的的依据。依据。SCR是保证软件版本进化可跟踪性所必须的文档。是保证软件版本进化可跟踪性所必须的文档。第34页，本讲稿共78页15.3.3 维护过程的事件流维护过程的事件流用户的维护请求提交给维护组织后的信用户的维护请求提交给维护组织后的信息流程如图息流程如图15-4-2所示。收到维护请求所示。收到维护请求后，维护组织首先要判断维护的类型，后，维护组织首先要判断维护的类型，即本次维护请求是纠错性维护还是其他即本次维护请求是纠错性维护还是其他类型的维护。对于纠错维护要启动纠错类型的维护。对于纠错维护要启动纠错维护流程，如果是其他类型的维护则启维护流程，如果是其他类型的维护则启动适应性或改善性维护流程。用户和维动适应性或改善性维护流程。用户和维护组织有时会对维护的类型有不同的看护组织有时会对维护的类型有不同的看法。法。第35页，本讲稿共78页15.3.3 维护活动的事件流维护活动的事件流第36页，本讲稿共78页软件维护的实施步骤软件维护的实施步骤严重性严重性评价评价错误错误分析分析优先度优先度评价评价维护维护过程过程配置配置复审复审问题问题分析分析区分区分类型类型纠错项目表纠错项目表维护人维护人员名单员名单 完善完善 适应适应纠错纠错开发项目表开发项目表 高高低低已修改已修改的配置的配置批准交付批准交付用户的配用户的配置置已修改已修改的软件的软件测试测试*维护人维护人员名单员名单严重严重不严重不严重 第37页，本讲稿共78页15.3.3 维护过程的事件流维护过程的事件流 确认维护类型确认维护类型 实施维护实施维护 维护评审维护评审 第38页，本讲稿共78页软件维护的管理流程软件维护的管理流程软件维护的管理流程软件维护的管理流程NYNYYN第39页，本讲稿共78页15.3.4 保存维护记录保存维护记录为为了了能能够够很很好好地地评评价价维维护护的的有有效效性性，必必须须详详细细记记录录软软件维护过程中的各种数据，这些数据包括：件维护过程中的各种数据，这些数据包括：（1）程序标志；）程序标志；（2）源程序行数；）源程序行数；（3）目标程序的指令条数；）目标程序的指令条数；（4）所用的编程语言；）所用的编程语言；（5）安装程序的日期；）安装程序的日期；（6）自安装之日起程序运行的次数；）自安装之日起程序运行的次数；（7）自安装之日起程序失败的次数；）自安装之日起程序失败的次数；（8）程序修改处的层数和标志；）程序修改处的层数和标志；第40页，本讲稿共78页15.3.4 保存维护记录保存维护记录（9）因程序变动而增加和删除的源程序行数；）因程序变动而增加和删除的源程序行数；（10）每处改动所耗费的人时数；）每处改动所耗费的人时数；（11）程序改动的日期；）程序改动的日期；（12）软件工程师标志；）软件工程师标志；（13）MRF的标志；的标志；（14）本次维护的类型；）本次维护的类型；（15）维护开始和结束的日期；）维护开始和结束的日期；（16）用于本次维护累计的人时数；）用于本次维护累计的人时数；（17）执行本次维护的纯利润。）执行本次维护的纯利润。上述数据应保存到维护数据库里，作为维护评价的依据。上述数据应保存到维护数据库里，作为维护评价的依据。第41页，本讲稿共78页15.3.5 评价维护活动评价维护活动通通过过每每次次维维护护活活动动的的详详细细记记录录，可可通通过过下下面面的的指指标标度度量维护的有效性：量维护的有效性：（1）程序运行的平均失效次数（失效次数运）程序运行的平均失效次数（失效次数运 行的次数）；行的次数）；（2）维护活动耗费的总人时数；）维护活动耗费的总人时数；（3）各种程序，及各种语言的平均变动数；）各种程序，及各种语言的平均变动数；（4）维护阶段修改每条语句所花费的人时数；）维护阶段修改每条语句所花费的人时数；（5）维护每种语言的程序平均花费的人时数；）维护每种语言的程序平均花费的人时数；（6）一张）一张MRF的平均周转时间；的平均周转时间；（7）各类维护请求的百分比。）各类维护请求的百分比。第42页，本讲稿共78页15.3.6 软件维护的实施软件维护的实施l软件维护，最终落实在修改源程序和文软件维护，最终落实在修改源程序和文档上。为了正确、有效地修改源程序，档上。为了正确、有效地修改源程序，通常要先分析和理解源程序，然后修改通常要先分析和理解源程序，然后修改源程序，最后重新检查和验证源程序源程序，最后重新检查和验证源程序 第43页，本讲稿共78页15.3.6 软件维护的实施软件维护的实施修改源程序的三个步骤修改源程序的三个步骤分析和理解程序分析和理解程序修改程序修改程序重新验证程序重新验证程序静态确认静态确认计算机确认计算机确认维护后的验收维护后的验收 第44页，本讲稿共78页q软件维护的概念软件维护的概念q软件维护分类软件维护分类q软件维护活动软件维护活动v结构化维护和非结构化维护结构化维护和非结构化维护v维护成本维护成本v维护可能存在的问题维护可能存在的问题q软件维护过程软件维护过程v维护机构维护机构/组织组织v维护流程维护流程v软件维护文档软件维护文档q维护的副作用维护的副作用q软件的可维护性软件的可维护性q软件维护的新方法软件维护的新方法软件工程软件工程软件维护软件维护 第45页，本讲稿共78页15.4 维护的副作用维护的副作用l软件修改是一项很危险的工作，对一个复杂软件修改是一项很危险的工作，对一个复杂的逻辑过程，那怕做一项微小的改动，都可的逻辑过程，那怕做一项微小的改动，都可能引入潜在的错误，虽然设计文档化和细致能引入潜在的错误，虽然设计文档化和细致的回归测试有助于排除错误，但是维护仍然的回归测试有助于排除错误，但是维护仍然会产生副作用。会产生副作用。一次修改一次修改5-10个语句，成功率个语句，成功率50%；一次修改一次修改40-50个语句，成功的可能性个语句，成功的可能性20%；每纠正一个错误平均需修改每纠正一个错误平均需修改17条指令。条指令。第46页，本讲稿共78页15.4 维护的副作用维护的副作用l软件修改是一项很危险的工作，对一个复杂的逻辑过程，软件修改是一项很危险的工作，对一个复杂的逻辑过程，那怕做一项微小的改动，都可能引入潜在的错误，虽然设那怕做一项微小的改动，都可能引入潜在的错误，虽然设计文档化和细致的回归测试有助于排除错误，但是维护仍计文档化和细致的回归测试有助于排除错误，但是维护仍然会产生副作用。然会产生副作用。l软件维护的副作用指，由于维护或在维护过程中其他软件维护的副作用指，由于维护或在维护过程中其他一些不期望的行为引入的错误，副作用大致可分为三一些不期望的行为引入的错误，副作用大致可分为三类类:(1)代码副作用代码副作用(2)数据副作用数据副作用数据副作用数据副作用(3)文档的副作用文档的副作用 第47页，本讲稿共78页15.4 维护的副作用维护的副作用维护的副作用是指，由于维护或在维护过程中其他维护的副作用是指，由于维护或在维护过程中其他一些不期望的行为引入的错误。副作用可分三类：一些不期望的行为引入的错误。副作用可分三类：（1）代码副作用）代码副作用下面的修改最易引起副作用：下面的修改最易引起副作用：修改或删除子程序；修改或删除子程序；修改或删除语句标号；修改或删除语句标号；修改或删除标识符；修改或删除标识符；为提高程序效率而做的修改；为提高程序效率而做的修改；修改逻辑操作符；修改逻辑操作符；由设计变动引起的代码修改；由设计变动引起的代码修改；修改分支处的判断条件；修改分支处的判断条件；代码副作用大多数可在回归测试中发现。代码副作用大多数可在回归测试中发现。第48页，本讲稿共78页15.4 维护的副作用维护的副作用（2）数据副作用）数据副作用数数据据副副作作用用是是由由于于修修改改数数据据结结构构带带来来的的副副作作用用。容容易易引引起数据副作用的修改包括：起数据副作用的修改包括：局部和全局常量的再定义；局部和全局常量的再定义；记录或文件格式的再定义；记录或文件格式的再定义；增减数据或是由于修改数据结构的定义导致增减数据或是由于修改数据结构的定义导致 数据结构长度的改变；数据结构长度的改变；修改全局数据；修改全局数据；重新初始化控制标志和指针；重新初始化控制标志和指针；重新排列重新排列I/O表或子程序参数表。表或子程序参数表。设设计计文文档档化化有有助助于于抑抑制制数数据据副副作作用用，在在设设计计文文档档中有关于数据结构的详细描述和交叉访问表。中有关于数据结构的详细描述和交叉访问表。第49页，本讲稿共78页15.4 维护的副作用维护的副作用（3）文档副作用）文档副作用l由于程序修改而没有对文档进行相应的修由于程序修改而没有对文档进行相应的修改引起文档的副作用。改引起文档的副作用。l必须保持文档和程序的一致性。每次维必须保持文档和程序的一致性。每次维护之后，再次交付软件之前应仔细评审护之后，再次交付软件之前应仔细评审整个配置，这样才能更好地减少文档的整个配置，这样才能更好地减少文档的副作用。副作用。第50页，本讲稿共78页q软件维护的概念软件维护的概念q软件维护分类软件维护分类q软件维护活动软件维护活动v结构化维护和非结构化维护结构化维护和非结构化维护v维护成本维护成本v维护可能存在的问题维护可能存在的问题q软件维护过程软件维护过程v维护机构维护机构/组织组织v维护流程维护流程v软件维护文档软件维护文档q维护的副作用维护的副作用q软件的可维护性软件的可维护性q软件维护的新方法软件维护的新方法软件工程软件工程软件维护软件维护 第51页，本讲稿共78页15.5 软件的可维护性软件的可维护性可维护性（可维护性（maintainability）软件的可维护性是指软件被理解和被正软件的可维护性是指软件被理解和被正确改动的难易程度。确改动的难易程度。软件的可维护性差是软件维护工作量和软件的可维护性差是软件维护工作量和费用激增的直接原因，因此在软件工程费用激增的直接原因，因此在软件工程的各个阶段都要保证软件具有较高可维的各个阶段都要保证软件具有较高可维护性，从而降低软件维护成本，这是软护性，从而降低软件维护成本，这是软件工程的重要目标之一。件工程的重要目标之一。第52页，本讲稿共78页15.5.1 影响可维护性的因素影响可维护性的因素软件的可维护性主要受下面因素影响：软件的可维护性主要受下面因素影响：（1）软件的构造过程是否严格按照软件工）软件的构造过程是否严格按照软件工 程的方法进行；程的方法进行；（2）开发团队是否训练有素；）开发团队是否训练有素；（3）软件的开发平台（操作系统和开发语）软件的开发平台（操作系统和开发语 言）是否标准。言）是否标准。总总结结起起来来就就是是：开开发发团团队队（人人）是是否否使使用用了通用的工具采用标准的方法来构造软件。了通用的工具采用标准的方法来构造软件。第53页，本讲稿共78页15.5.2 可维护性的度量可维护性的度量通过维护记录可间接度量可维护性。通过维护记录可间接度量可维护性。（1）问问题题、收收集集维维护护工工具具以以及及分分析析问问题题所所用的时间；用的时间；（2）形成修改说明书所用的时间；）形成修改说明书所用的时间；（3）修改设计和源代码所用的时间；）修改设计和源代码所用的时间；（4）测试所用时间；）测试所用时间；（5）复审所用时间；）复审所用时间；（6）完全恢复所用时间。）完全恢复所用时间。以上时间越短则软件的可维护性越好。以上时间越短则软件的可维护性越好。第54页，本讲稿共78页15.5.3 文档与软件的可维护性文档与软件的可维护性l文档文档文档是文档是影响软件可维护性的决定因素影响软件可维护性的决定因素。由于长。由于长期使用的大型软件系统在使用过程中必然会经期使用的大型软件系统在使用过程中必然会经受多次修改，所以受多次修改，所以文档比程序代码更重要文档比程序代码更重要。文档类型文档类型l用户文档用户文档描述系统功能和使用方法，不关心这些功能是怎样描述系统功能和使用方法，不关心这些功能是怎样实现的；实现的；l系统文档系统文档描述系统设计、实现和测试等各方面的内容。描述系统设计、实现和测试等各方面的内容。第55页，本讲稿共78页15.5.3 可维护性复审可维护性复审在软件工程每一阶段的复审中，可维护性都是一个重要在软件工程每一阶段的复审中，可维护性都是一个重要的指标。的指标。在需求分析阶段的复审中，应在规格说明书中对将在需求分析阶段的复审中，应在规格说明书中对将来可能修改和可以改进的部分加以注明；来可能修改和可以改进的部分加以注明；在设计阶段的复审中，应该从易于维护和提高设计在设计阶段的复审中，应该从易于维护和提高设计总体质量的角度对设计进行全面评审；总体质量的角度对设计进行全面评审；代码复审主要审查代码风格和内部文档（程序注释等）代码复审主要审查代码风格和内部文档（程序注释等）这两个直接影响可维护性的因素。这两个直接影响可维护性的因素。最后，每一阶段性测试，直到软件正式交付之前，最后，每一阶段性测试，直到软件正式交付之前，都应该进行的预防性维护。都应该进行的预防性维护。正式的可维护性复审放在测试完成之后，称为配置复审。正式的可维护性复审放在测试完成之后，称为配置复审。目的是保证配置中所有成分的完整、一致、易于理解且便目的是保证配置中所有成分的完整、一致、易于理解且便于修改控制。于修改控制。第56页，本讲稿共78页主讲内容主讲内容l软件维护的分类软件维护的分类l维护活动维护活动l软件维护过程软件维护过程l维护的副作用维护的副作用l软件的可维护性软件的可维护性l软件再工程：逆向工程和重构工程软件再工程：逆向工程和重构工程 第57页，本讲稿共78页预防性维护预防性维护 开发和维护者不应等待用户的维护申请开发和维护者不应等待用户的维护申请,可先选择以下类型程序作为预防性维护可先选择以下类型程序作为预防性维护对象对象:预计若干年内将继续使用的程序预计若干年内将继续使用的程序当今正成功使用的程序当今正成