软件维护技术

1软件维护技术学习目标掌握软件维护的概念及类型掌握软件维护的过程掌握软件维护的可维护性掌握提高软件可维护性的途径2软件维护技术教学内容：1软件维护概述2软件维护的过程3软件的可维护性4提高可维护性的途径5逆向工程和再工程31软件维护概述1.1软件维护的基本概念把软件运行/维护阶段对软件产品所作的修改定义为软件维护。进行软件维护的原因有很多，主要有以下几个方面：改正在特定的使用条件下暴露出来的一些潜在的程序错误或程序设计缺陷。在软件使用过程中数据环境发生了变化（如事务处理代码发生改变）或处理环境发生了变化（如安装了新的硬件或操作系统），需要对软件进行修改以适应这种变化的需求。用户和数据处理人员在使用软件时需要改进现有的功能、增加新的功能、改善总体性能等，为满足这些要求，需要对软件进行修改以便把这些要求纳入到软件之中。返回目录41软件维护概述1.2软件维护的种类软件维护是为了满足用户对已开发产品的性能与运行环境不断提高的需要，达到延长软件的寿命的目的。按照这一目标，维护分如下几类：1．改正性维护（CorrectiveMaintenance）为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，而应当进行的诊断和改正错误的过程，就叫做改正性维护。2．适应性维护（AdaptiveMaintenance）随着计算机技术的飞速发展，外部环境（新的硬、软件配置）或数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）可能发生变化，为了使软件适应变化，修改软件的过程叫做适应性维护。返回目录51软件维护概述3．完善性维护（PerfectiveMaintenance）软件在使用的过程中，用户常常会对软件提出新的功能与性能的要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性,这种情况下进行的维护活动叫做完善性维护。4．预防性维护（PreventiveMaintenance）为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。通常，预防性维护定义为：“把今天的方法学用于昨天的系统以满足明天的需要”。也就是说，采用先进的软件工程方法对需要维护的软件或软件中的某一部分进行（重新）设计、编制和测试。返回目录61软件维护概述在整个软件维护阶段所花费的全部工作量中，预防性维护只占很小的比例，而完善性维护占了几乎一半的工作量，参看图1。图1三类维护占总维护比例图2维护在软件生存期所占比例从图2中可以看到，软件维护活动所花费的工作占整个生存期工作量的70%以上。返回目录71软件维护概述1.3影响软件维护工作量的因素维护中，影响维护工作量的程序特性有以下几种:（1）系统的大小（2）程序设计语言（3）系统年龄（4）数据库技术的应用（5）先进的软件开发技术（6）其他方面此外，许多软件在开发时并未考虑将来的修改，这就为软件的维护带来许多问题。返回目录81软件维护概述1.4软件维护的策略JamesMartin等提出了一些维护策略，以控制维护成本。1．改正性维护要生成100%可靠的软件，成本太高。可通过新技术提高可靠性，减少进行改正性维护的需要。这些技术包括：数据库管理系统、软件开发环境、程序自动生成系统、较高级（第四代）的语言。应用以上4种方法可产生更加可靠的代码。此外：（1）利用应用软件包，可开发出可靠性更高的软件。（2）结构化技术。用它开发的软件易于理解和测试。（3）防错性程序设计。把自检能力引入程序，通过检查，提供审查跟踪。（4）通过周期性维护审查，在形成维护问题之前就可确定质量缺陷。返回目录91软件维护概述2．适应性维护这一类维护不可避免，但可以控制。（1）在配置管理时，把硬件、操作系统和其他相关环境因素的可能变化考虑在内，可以减少某些适应性维护的工作量。（2）把与硬件、操作系统，以及其他外围设备有关的程序归到特定的程序模块中；把因环境变化而必须修改的程序局部于某些程序模块之中。（3）使用内部程序列表、外部文件，以及处理的例行程序包，可为维护时修改程序提供方便。返回目录101软件维护概述3．完善性维护利用前两类维护中列举的方法，也可以减少这一类维护。特别是数据库管理系统、程序生成器、应用软件包，可减少系统或程序员的维护工作量。此外，建立软件系统的原型，把它在实际系统开发之前提供给用户。用户通过研究原型，进一步完善他们的功能要求，就可以减少以后完善性维护的需要。返回目录111软件维护概述1.5修改程序的副作用所谓副作用是指因修改软件而造成的错误或其它不希望发生的情况，有三种副作用：（1）修改代码的副作用。在使用程序设计语言修改源代码时，都可能引入错误。例如，删除或修改一个子程序、删除或修改一个标号、删除或修改一个标识符、改变程序代码的时序关系、改变占用存储的大小、改变逻辑运算符、修改文件的打开或关闭、改进程序的执行效率，以及把设计上的改变翻译成代码的改变、为边界条件的逻辑测试做出改变时，都容易引入错误。返回目录121软件维护概述（2）修改数据的副作用。在修改数据结构时，有可能造成软件设计与数据结构不匹配，因而导致软件出错。数据副作用就是修改软件信息结构导致的结果。例如，在重新定义局部的或全局的常量、重新定义记录或文件的格式、增大或减小一个数组或高层数据结构的大小、修改全局或公共数据、重新初始化控制标志或指针、重新排列输入／输出或子程序的参数时，容易导致设计与数据不相容的错误。数据副作用可以通过详细的设计文档加以控制。在此文档中描述了一种交叉引用，把数据元素、记录、文件和其它结构联系起来。返回目录131软件维护概述（3）文档的副作用。对数据流、软件结构、模块逻辑或任何其它有关特性进行修改时，必须对相关技术文档进行相应修改。否则软件文档不能反映软件的当前状态。如果对可执行软件的修改不反映在文档里，就会产生文档的副作用。例如，对交互输入的顺序或格式进行修改，如果没有正确地记入文档中，就可能引起重大的问题。过时的文档内容、索引和文本可能造成冲突，引起用户的失败和不满。因此，必须在软件交付之前对整个软件配置进行评审，以减少文档的副作用。返回目录141软件维护概述为了控制因修改而引起的副作用，要做到：按模块把修改分组；自顶向下地安排被修改模块的顺序；每次修改一个模块；对于每个修改了的模块，在安排修改下一个模块之前，要确定这个修改的副作用。可以使用交叉引用表、存储映象表、执行流程跟踪等。返回目录152软件维护的过程为了有效地进行软件维护，应事先就开始做组织工作。首先需要建立维护的机构，申明提出维护申请报告的过程及评价的过程；为每一个维护申请规定标准的处理步骤；还必须建立维护活动的登记制度以及规定评价和评审的标准。2.1维护机构如图3就是一个维护机构的组织方案。返回目录162软件维护的过程图3软件维护的机构返回目录172软件维护的过程维护申请提交给一个维护管理员，他把申请交给某个系统监督员去评价。系统监督员是一位技术人员，他必须熟悉产品程序的每一部分。一旦做出评价，由修改负责人确定如何进行修改。在维护人员对程序进行修改的过程中，由配置管理员严格把关，控制修改的范围，对软件配置进行审计。修改负责人、维护管理员可以是指定的某个人，也可以是一个包括管理人员、高级技术人员在内的小组。系统监督员可以有其他职责，但应具体分管某一个软件包。在开始维护之前，就把责任明确下来，可以大大减少维护过程中的混乱。返回目录182软件维护的过程2.2软件维护申请报告所有软件维护申请应按规定的方式提出。软件维护组织通常提供维护申请报告（MRP，MaintenanceRequestForm），或称软件问题报告，由申请维护的用户填写。如果遇到一个错误，用户必须完整地说明产生错误的情况，包括输入数据、错误清单以及其他相关材料。如果申请的是适应性维护或完善性维护，用户必须提供一份修改说明书，列出所有希望的修改。维护申请报告将由维护管理员和系统监督员来研究处理。返回目录192软件维护的过程维护申请报告是由软件组织外部提交的文档，它是计划维护工作的基础。软件组织内部应相应地做出软件修改报告（SCR，SoftwareChangeReport），指明：所需修改变动的性质；申请修改的优先级；为满足某个维护申请报告，所需的工作量；预计修改后的状况。软件修改报告应提交修改负责人，经批准后才能开始进一步安排维护工作。返回目录202软件维护的过程2.3软件维护工作流程图4软件维护的工作流图返回目录212软件维护的过程首先，第一步是先确认维护要求。然后由维护组织管理员确认维护类型。对于改正性维护申请，从评价错误的严重性开始。对于适应性维护和完善性维护申请，需要先确定每项申请的优先次序。尽管维护申请的类型不同，但都要进行同样的技术工作。这些工作有：修改软件需求说明、修改软件设计、设计评审、对源程序做必要的修改、单元测试、集成测试（回归测试）、确认测试、软件配置评审等。返回目录222软件维护的过程在每次软件维护任务完成后，最好进行一次情况评审，对以下问题做一总结：（1）在目前情况下，设计、编码、测试中的哪一方面可以改进？（2）哪些维护资源应该有但没有？（3）工作中主要的或次要的障碍是什么？（4）从维护申请的类型来看是否应当有预防性维护？情况评审对将来的维护工作如何进行会产生重要的影响，并可为软件机构的有效管理提供重要的反馈信息。返回目录232软件维护的过程2.4软件维护记录及评价在维护的过程中做好维护档案记录。其内容包括程序名称、源程序语句条数、机器代码指令条数、所用的程序设计语言、程序安装的日期、程序安装后的运行次数、与程序安装后运行次数有关的处理故障次数、程序改变的层次及名称、修改程序所增加的源程序语句条数、修改程序所减少的源程序语句条数、每次修改所付出的“人时”数、修改程序的日期、软件维护人员的姓名、维护申请报告的名称、维护类型、维护开始时间和维护结束时间、花费在维护上的累计“人时”数、维护工作的净收益等。对每项维护任务都应该收集上述数据。返回目录242软件维护的过程维护完成后，还需要对维护的结果进行评价。可参考的度量值如下：每次程序运行时的平均出错次数；花费在每类维护上的总“人时”数；每个程序、每种语言、每种维护类型的程序平均修改次数；用于每种语言的平均“人时”数；因为维护，增加或删除每个源程序语句所花费的平均“人时”数；维护申请报告的平均处理时间；各类维护申请的百分比。这七种度量值提供了定量的数据，据此可对开发技术、语言选择、维护工作计划、资源分配、以及其他许多方面做出判定。因此，这些数据可以用来评价维护工作。返回目录253软件的可维护性为了使得软件能够易于维护，必须考虑使软件具有可维护性。3.1可维护性的定义软件可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的要求而进行修改、扩充或压缩的容易程度。可维护性、可使用性、可靠性是衡量软件质量的几个主要质量特性，也是用户十分关心的几个方面。由于影响软件质量的这些重要因素，目前还没有对它们定量度量的普遍适用方法。但是就它们的概念和内涵来说则是很明确的。软件的可维护性是软件开发阶段各个时期的关键目标。返回目录263软件的可维护性目前广泛使用的是用如下的七个特性来衡量程序的可维护性。而且对于不同类型的维护，这七种特性的侧重点也不相同。表1显示了在各类维护中应侧重哪些特性。表中的“”表示需要的特性。改正性维护适应性维护完善性维护可理解性可测试性可修改性可靠性可移植性可使用性效率表1在各类维护中的侧重点返回目录273软件的可维护性3.2可维护性的度量度量一个可维护的程序的七种特性时常用的方法就是质量检查表、质量测试、质量标准。质量检查表是用于测试程序中某些质量特性是否存在的一个问题清单。评价者针对检查表上的每一个问题，依据自己的定性判断，回答“Yes”或者“No”。质量测试与质量标准则用于定量分析和评价程序的质量。由于许多质量特性是相互抵触的，要考虑几种不同的度量标准，相应地去度量不同的质量特性。返回目录283软件的可