软件维护整理PPT课件

-软件维护软件维护软件工程第八章软件工程第八章首都师范大学教育技术系首都师范大学教育技术系 方海光方海光2006年年10月月编程大师曾说过：编程大师曾说过：“哪怕程序只有哪怕程序只有三行长，总有一天你也不得不对它三行长，总有一天你也不得不对它进行维护进行维护。”在软件开发过程中始终强调软件的在软件开发过程中始终强调软件的可维护性可维护性。原因是，一个应用系统由于需求和环境的变化原因是，一个应用系统由于需求和环境的变化以及自身暴露的问题，在交付用户使用后，对以及自身暴露的问题，在交付用户使用后，对它进行维护是不可避免的，统计和估测结果表它进行维护是不可避免的，统计和估测结果表明，信息技术中明，信息技术中硬件费用一般占硬件费用一般占35%，软件占，软件占65%，而软件，而软件后期维护费用后期维护费用有时竟高达软件总有时竟高达软件总费用的费用的80%，所有前期开发费用仅占，所有前期开发费用仅占20%。许多大型软件公司为维护已有软件耗费大量人许多大型软件公司为维护已有软件耗费大量人力、财力。因此，必须建立一套评估、控制和力、财力。因此，必须建立一套评估、控制和实施软件维护的机制，这就是本章重点讨论的实施软件维护的机制，这就是本章重点讨论的内容。内容。内容提要内容提要软件维护的定义软件维护的定义软件维护的类型软件维护的类型结构化维护结构化维护VS非结构化维护非结构化维护影响软件维护工作量的因素影响软件维护工作量的因素软件维护的过程软件维护的过程可维护性可维护性软件维护的管理软件维护的管理软件维护的定义软件维护的定义软件维护软件维护是指软件系统交付使用以后，是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软为了改正错误或满足新的需要而修改软件的过程。件的过程。一一般般来来说说，要要求求进进行行维维护护的的原原因因大大致致有有以下几种：以下几种：（1）改正程序中的错误和缺陷。）改正程序中的错误和缺陷。（2）改进设计以适应新的软、硬件环境。）改进设计以适应新的软、硬件环境。（3）增加新的应用范围。）增加新的应用范围。软件维护的类型软件维护的类型根据软件维护的不同原因，软件维护可根据软件维护的不同原因，软件维护可以分成三种类型：以分成三种类型：改正性维护改正性维护适应性维护适应性维护完善性维护完善性维护预防性维护预防性维护改正性维护改正性维护在软件交付使用后，在软件交付使用后，因开发时测试的不彻底、因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行不完全，必然会有部分隐藏的错误遗留到运行阶段。阶段。这些隐藏下来的错误在某些特定的使用环境下这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。就会暴露出来。为了识别和纠正软件错误、改正软件性能上的为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护。和改正错误的过程就叫做改正性维护。适应性维护适应性维护在使用过程中，在使用过程中，外部环境（新的硬、软件配置）外部环境（新的硬、软件配置）数据环境（数据库、数据格式、数据输入数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）输出方式、数据存储介质）可能发生变化。可能发生变化。为使软件适应这种变化，而去修改软件为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。的过程就叫做适应性维护。完善性维护完善性维护在软件的使用过程中，用户往往会对软在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发为了满足这些要求，需要修改或再开发软件，以扩充软件功能、软件，以扩充软件功能、增强软件性能增强软件性能、改进加工效率改进加工效率、提高软件的可维护性。、提高软件的可维护性。这种情况下进行的维护活动叫做完善性这种情况下进行的维护活动叫做完善性维护。维护。预防性维护预防性维护预防性维护即预防性维护即软件再工程软件再工程，是为了提高，是为了提高软件的可维护性、可靠性等，为以后进软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。一步改进软件打下良好基础。采用先进的软件工程方法对需要维护的采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行软件或软件中的某一部分（重新）进行设计、编制和测试，称为预防性维护。设计、编制和测试，称为预防性维护。各种维护类型和维护工作量的比例各种维护类型和维护工作量的比例其它其它维护维护4%适应性适应性维维 护护18-25%改正性改正性维护维护1721%完善性维护完善性维护50%66维护占维护占70.8%改改正正性维护占全部维护工作量的比率已从上世性维护占全部维护工作量的比率已从上世纪纪8080年代初的年代初的20%20%大幅度下降大幅度下降,上世纪上世纪9090年代年代初一些公司的产品差错率已接近于零初一些公司的产品差错率已接近于零!软件维护的特点软件维护的特点结构化维护和非结构化维护差别巨大结构化维护和非结构化维护差别巨大软件维护的代价高昂软件维护的代价高昂维护问题多维护问题多软件维护事件流软件维护事件流结构化维护结构化维护VS非结构化维护非结构化维护软件的开发过程对软件的维护产生较大的影响。软件的开发过程对软件的维护产生较大的影响。如果采用软件工程的方法进行软件开发，保证每个如果采用软件工程的方法进行软件开发，保证每个阶段都有完整且详细的文档，这样维护会相对容易，阶段都有完整且详细的文档，这样维护会相对容易，被称为被称为结构化的维护结构化的维护。反之，如果不采用软件工程方法开发软件，软件只反之，如果不采用软件工程方法开发软件，软件只有程序而欠缺文档，则维护工作变得十分困难，被有程序而欠缺文档，则维护工作变得十分困难，被成为成为非结构化的维护非结构化的维护。结构化维护结构化维护非结构化维护非结构化维护程序程序文档文档结构化维护结构化维护VS非结构化维护非结构化维护交付使用交付使用分析设计分析设计制定计划制定计划修改计划修改计划编码编码复审通过复审通过文件有吗文件有吗苦读代码苦读代码找到问题找到问题编码编码复审通过复审通过维护要求维护要求n ny yy yy yy yn nn nn n结构化维护结构化维护 非结构化维护非结构化维护 维护要求维护要求配置配置评价设计评价设计计划途径计划途径修改设计修改设计重编程序重编程序评价代码评价代码？重编程序重编程序复查复查复查复查交付使用交付使用软件软件代码代码结结构构化化维维护护非非结结构构化化维维护护非结构化维护非结构化维护在非结构化维护过程中，开发人员只能通过阅在非结构化维护过程中，开发人员只能通过阅读、理解和分析源程序来了解系统功能、软件读、理解和分析源程序来了解系统功能、软件结构、数据结构、系统接口和设计约束等，这结构、数据结构、系统接口和设计约束等，这样做是十分困难的，也容易产生误解。要弄清样做是十分困难的，也容易产生误解。要弄清楚整个系统，势必要花费大量的人力和物力，楚整个系统，势必要花费大量的人力和物力，对源程序修改产生的后果难以估计。在没有文对源程序修改产生的后果难以估计。在没有文档的情况下，也不可能进行回归测试，很难保档的情况下，也不可能进行回归测试，很难保证程序的正确性。证程序的正确性。结构化维护结构化维护在结构化维护的过程中，所开发的软件具有各在结构化维护的过程中，所开发的软件具有各个阶段的文档，它对于理解和掌握软件的功能、个阶段的文档，它对于理解和掌握软件的功能、性能、体系结构、数据结构、系统接口和设计性能、体系结构、数据结构、系统接口和设计约束等有很大的作用。维护时，开发人员从分约束等有很大的作用。维护时，开发人员从分析需求规格说明开始，明白软件功能和性能上析需求规格说明开始，明白软件功能和性能上的改变，对设计说明文档进行修改和复查，再的改变，对设计说明文档进行修改和复查，再根据设计修改进行程序变动，并用测试文档中根据设计修改进行程序变动，并用测试文档中的的测试用例进行回归测试测试用例进行回归测试，最后将修改后的软，最后将修改后的软件再次交付使用。这种维护有利于减少工作量件再次交付使用。这种维护有利于减少工作量和降低成本，大大提高软件的维护效率。和降低成本，大大提高软件的维护效率。软件维护的代价高昂软件维护的代价高昂有形代价逐年上升：有形代价逐年上升：19701970年软件维护费用占总费用的年软件维护费用占总费用的35%40%35%40%；19801980年软件维护费用占总费用的年软件维护费用占总费用的40%60%40%60%；19901990年软件维护费用占总费用的年软件维护费用占总费用的70%80%70%80%。软件维护的代价高昂软件维护的代价高昂维护费用只不过是软件维护最明显的代价，其他维护费用只不过是软件维护最明显的代价，其他一些还不明显的代价将来可能更为人们关注。其一些还不明显的代价将来可能更为人们关注。其他无形的代价还有：他无形的代价还有：可用的资源被软件维护所占用。可用的资源被软件维护所占用。未能及时满足用户的维护要求时引起用户不满。未能及时满足用户的维护要求时引起用户不满。维护时改动软件，引入了潜在故障，降低了软件质量。维护时改动软件，引入了潜在故障，降低了软件质量。抽调人员从事维护工作，对新的开发过程造成混乱。抽调人员从事维护工作，对新的开发过程造成混乱。导致生产率的大幅下降。导致生产率的大幅下降。软件维护的代价高昂软件维护的代价高昂用于维护工作的劳动可以划分成：用于维护工作的劳动可以划分成：生产性活动生产性活动（如，分析评价、修改设计、编写程序（如，分析评价、修改设计、编写程序代码等）代码等）非生产性活动非生产性活动（例如，理解程序代码功能、解释数（例如，理解程序代码功能、解释数据结构、接口特点、性能限度等）据结构、接口特点、性能限度等）软件维护的代价高昂软件维护的代价高昂下述表达式给出了维护工作量的一个模型：下述表达式给出了维护工作量的一个模型：其中，其中，M是维护的总工作量，是维护的总工作量，P是生产性工作是生产性工作量，量，K是经验常数，是经验常数，c是复杂程度，是复杂程度，d是维护人是维护人员对软件的熟悉程度员对软件的熟悉程度上述模型表明，上述模型表明，如果软件开发没有运用软件工如果软件开发没有运用软件工程方法学，而且原来的开发人员未能够参与到程方法学，而且原来的开发人员未能够参与到维护工作之中，则维护工作量和费用将指数增维护工作之中，则维护工作量和费用将指数增加。加。软件维护的问题软件维护的问题与软件维护有关的大多数问题都可归因于软件与软件维护有关的大多数问题都可归因于软件定义和开发方法上的不足。定义和开发方法上的不足。软件开发时采用急功近利，还是放眼未来的态软件开发时采用急功近利，还是放眼未来的态度，对软件维护影响极大。度，对软件维护影响极大。一般说来，软件开发若不严格遵循软件开发标一般说来，软件开发若不严格遵循软件开发标准，软件维护就会遇到许多困难。准，软件维护就会遇到许多困难。软件维护的问题软件维护的问题下面列出了和软件维护有关的部分问题：下面列出了和软件维护有关的部分问题：理解别人的代码通常是非常困难的，而且难度随着理解别人的代码通常是非常困难的，而且难度随着软件配置成分的缺失而迅速增加；软件配置成分的缺失而迅速增加；需要维护的软件通常往往没有合格的文档，或文档需要维护的软件通常往往没有合格的文档，或文档资料显然不足。资料显然不足。-认识到文档仅仅是第一步，容易认识到文档仅仅是第一步，容易理解且和程序保持一致的文档才是真正具有价值的理解且和程序保持一致的文档才是真正具有价值的；当软件要求维护时，不能指望开发人员给我们仔细当软件要求维护时，不能指望开发人员给我们仔细说明软件。由于维护持续时间很长，因此当需要解说明软件。由于维护持续时间很长，因此当需要解释软件时候，往往开发人员已经不在附近了；释软件时候，往往开发人员已经不在附近了；上述种种问题在现有没有采用软件工程思想开发出来的软上述种种问题在现有没有采用软件工程思想开发出来的软件中，都或多或少存在。件中，都或多或少存在。影响软件维护工作量的因素影响软件维护工作量的因素在软件维护中，影响维护工作量的因素主要有在软件维护中，影响维护工作量的因素主要有以下六种：以下六种：系统的大小系统的大小系统规模越大，其功能就越复杂，软件维护的工作系统规模越大，其功能就越复杂，软件维护的工作量也随之增大。量也随之增大。程序设计语言程序设计语言使用强功能的程序设计语言可以控制程序的规模。使用强功能的程序设计语言可以控制程序的规模。语言的功能越强，生成程序的模块化和结构化程度语言的功能越强，生成程序的模块化和结构化程度越高，所需的指令数就越少，程序的可读性越好。越高，所需的指令数就越少，程序的可读性越好。影响软件维护工作量的因素影响软件维护工作量的因素系统年龄系统年龄老系统比新系统需要更多的维护工作量老系统比新系统需要更多的维护工作量。因为。因为多次的修改可能造成系统结构变得混乱，由于多次的修改可能造成系统结构变得混乱，由于维护人员经常更换，程序变得越来越难于理解，维护人员经常更换，程序变得越来越难于理解，加之系统开发时文档不齐全，或在长期的维护加之系统开发时文档不齐全，或在长期的维护过程中文档在许多地方与程序实现变得不一致，过程中文档在许多地方与程序实现变得不一致，从而使维护变得十分困难。从而使维护变得十分困难。数据库技术的应用数据库技术的应用使用数据库，可以简单而有效地管理和存储用使用数据库，可以简单而有效地管理和存储用户程序中的数据，还可以减少生成用户报表应户程序中的数据，还可以减少生成用户报表应用软件的维护工作量。用软件的维护工作量。影响软件维护工作量的因素影响软件维护工作量的因素先进的软件开发技术先进的软件开发技术 在软件开发过程中，如果采用先进的分析设计在软件开发过程中，如果采用先进的分析设计技术和程序设计技术，如面向对象技术、复用技术和程序设计技术，如面向对象技术、复用技术等，可减少大量的维护工作量。技术等，可减少大量的维护工作量。其它一些因素其它一些因素如应用的类型、数学模型、任务的难度、开关如应用的类型、数学模型、任务的难度、开关与标记、与标记、IF嵌套深度、索引或下标数等，对维嵌套深度、索引或下标数等，对维护工作量也有影响。护工作量也有影响。软件维护的过程软件维护的过程软件维护工作在维护申请提出之前就开始了，软件维护工作在维护申请提出之前就开始了，它包括：它包括：建立维护组织，强制报告和评估的过程；建立维护组织，强制报告和评估的过程；为每个维护申请确定标准化的事件序列；为每个维护申请确定标准化的事件序列；制定保存维护活动记录的制度和有关复审制定保存维护活动记录的制度和有关复审及评估的标准。及评估的标准。维护阶段的工作事件流维护阶段的工作事件流维护组织维护组织维护决策机构维护决策机构维护管理员维护管理员系统管理员系统管理员维护人员维护人员配置管理员配置管理员维护申请维护申请每个维护申请通过维护管理员转告给系统管理员，系每个维护申请通过维护管理员转告给系统管理员，系统管理员一般都是对程序统管理员一般都是对程序(某一部分某一部分)特别熟悉的技术特别熟悉的技术人员，他们对维护申请及可能引起的软件修改进行评人员，他们对维护申请及可能引起的软件修改进行评估，并向修改控制决策机构估，并向修改控制决策机构(一个或一组管理者一个或一组管理者)报告，报告，由它最后确定是否采取行动。由它最后确定是否采取行动。在在维护活动开始之前维护活动开始之前就就明确维护责任明确维护责任是十分必要的，可以大是十分必要的，可以大大地减少维护过程中可能出现的混乱。大地减少维护过程中可能出现的混乱。维护团队组织维护团队组织维护报告维护报告MRF应该用标准的格式来表达维护要求。软件维护人应该用标准的格式来表达维护要求。软件维护人员通常提供给用户空白的维护请求表（报告）即员通常提供给用户空白的维护请求表（报告）即软件问题报告，该报告（表）由要求一项维护活软件问题报告，该报告（表）由要求一项维护活动的用户填写。动的用户填写。如遇到什么错误，用户需要详细描述错误出现的现场如遇到什么错误，用户需要详细描述错误出现的现场信息信息(包括输入数据、列表文件和其他有关信息包括输入数据、列表文件和其他有关信息)；对适应性维护、完善性维护应该给出一个简短的需求对适应性维护、完善性维护应该给出一个简短的需求规格说明书。最终由维护管理员和系统管理员评价用规格说明书。最终由维护管理员和系统管理员评价用户用户提出的维护请求表。户用户提出的维护请求表。一个维护申请被核准后，维护请求表就成为外部文档，视作一个维护申请被核准后，维护请求表就成为外部文档，视作规划本次维护任务的依据。规划本次维护任务的依据。软件维护请求报告评价负责人：*申请评价结果：修正错误批准 拒绝申请人：*环境 自 *年*月*日 至 *年*月*日 共计 0.5 人月维护时间维护要求及优先级：在测评之前必须修正，否则会造成测评结果的不准确软件：纠错维护 适应维护 完善维护硬件：系统设备 外部设备维护类型远程维护现场维护维护安排预计维护的结果：修正程序中的人员权限，使得每种类型的人员只能进行自身类型的测评。问题说明：(数据输入、错误现象)不同类型的人员可以进行交叉测评。按需求：各类人员只进行自身类型的测评，如管理人员只能对管理人员进行测评，教师只能测评教师。项目编号网络测评系统项目名称软件修改报告软件修改报告(SCR)依据维护请求表，软件组织内部应该制定出一依据维护请求表，软件组织内部应该制定出一个软件修改报告，它给出下述信息：个软件修改报告，它给出下述信息：满足维护请求表中提出的要求所需的工作量；满足维护请求表中提出的要求所需的工作量；维护要求的性质；维护要求的性质；维护要求的优先次序；维护要求的优先次序；与修改有关的背景数据。与修改有关的背景数据。在拟定进一步维护计划前，把软件修改报告提在拟定进一步维护计划前，把软件修改报告提交控制决策机构审查批准。交控制决策机构审查批准。有 无 有 无修改完成日期维护人修改开始日期相关文档修改注释修改修改代码行数删除代码行数增加代码行数相关文档列表备份程序名称源程序名称软件名称特别说明修改原因修改内容日期维护描述：软件修改报告软件修改报告(SCR)维护请求维护请求类型类型类型类型严重性严重性评估后按优先评估后按优先级在队列排队级在队列排队“救火行动救火行动”,”,当当排在队列之首排在队列之首评估后分类评估后分类评估后按优先评估后按优先级在队列排队级在队列排队采取的行动采取的行动通知请求者通知请求者并说明原因并说明原因按优先级在按优先级在队列中排队队列中排队从维护请求队列之首取出一任务从维护请求队列之首取出一任务按按SESE方法学规划、组织、实施工程方法学规划、组织、实施工程队列中还有维护请求吗？队列中还有维护请求吗？资源用于开发新的软件。资源用于开发新的软件。y yn n改正性改正性其他其他完善性完善性适应性适应性拒绝拒绝接受接受并不严重并不严重非常严重非常严重软软件件维维护护的的工工作作流流软件维护工作流软件维护工作流虽然每种维护请求类型着眼点不同，但总的维虽然每种维护请求类型着眼点不同，但总的维护方法是相同的。护方法是相同的。维护工作最后一步是复审，主要审查修改过的维护工作最后一步是复审，主要审查修改过的软件配置，以验证软件结构中的所有成分的功软件配置，以验证软件结构中的所有成分的功能，保证满足维护请求表中的要求。能，保证满足维护请求表中的要求。情况复审情况复审当一项软件维护任务完成之后，进行一次情况当一项软件维护任务完成之后，进行一次情况复审不无裨益。情况复审主要考虑下列问题复审不无裨益。情况复审主要考虑下列问题:依照当前状态，在设计、编码和测试的哪些方面还依照当前状态，在设计、编码和测试的哪些方面还能用其他方法进行能用其他方法进行?哪些维护资源可用但未用？哪些维护资源可用但未用？这次维护活动中主要这次维护活动中主要(或次要或次要)的障碍有哪些的障碍有哪些?在维护请求中有预防性维护吗在维护请求中有预防性维护吗?情况复审的目的在于促进未来的维护工作情况复审的目的在于促进未来的维护工作,同同时也为有效管理软件组织提供重要的反馈信息。时也为有效管理软件组织提供重要的反馈信息。软件维护记录的保存软件维护记录的保存有效的保存维护记录是极端重要的。有效的保存维护记录是极端重要的。保存维护记录的第一个问题就是那些数据值得保存？保存维护记录的第一个问题就是那些数据值得保存？Swanson为我们指出了下述内容：程序标识、源语为我们指出了下述内容：程序标识、源语句数、机器指令数、使用的程序设计语言、软件安句数、机器指令数、使用的程序设计语言、软件安装的日期、自安装以来软件运行的次数、自安装以装的日期、自安装以来软件运行的次数、自安装以来软件失败的次数、程序变动的层次和标识、因程来软件失败的次数、程序变动的层次和标识、因程序变动而增加的源语句数、因程序变动而删除的源序变动而增加的源语句数、因程序变动而删除的源语句数、每个改动消耗的人时数、程序改动的日期、语句数、每个改动消耗的人时数、程序改动的日期、软件工程师的名称、维护要求的标识、维护类型、软件工程师的名称、维护要求的标识、维护类型、维护开始和完成的时间、用于维护的累计人时数、维护开始和完成的时间、用于维护的累计人时数、与完成的维护相关联的纯收益。与完成的维护相关联的纯收益。应该为每项维护工作都收集上述数据。可以利用这应该为每项维护工作都收集上述数据。可以利用这些数据构成一个维护数据库。些数据构成一个维护数据库。软软件维护记录件维护记录维护结维护结果：果：经过对经过对需求的需求的进进一步确一步确认认，对对指定指定编编号的模号的模块进块进行了修改，行了修改，纠纠正了源正了源程序中出程序中出现现的的错误错误。维护维护人人员员：*0.2个人月个人月修改部分源程序修改部分源程序查错查错，确定，确定错误错误位置位置*月月*日日维护维护人人员员工作量工作量增增/删删/改改维护维护内容内容日期日期编编号：号：evalobject_01机器指令机器指令长长度：度：25Kb程序安装日期：程序安装日期：*年年*月月*日日程序运行程序运行时间时间：模模块块名称：名称：测评测评控制管理控制管理源程序行数：源程序行数：210编编程程语语言：言：PHP失效次数：失效次数：3初始状初始状态态描述：不同描述：不同类类型的人型的人员员可以可以进进行交叉行交叉测评测评。按需求：各。按需求：各类类人人员员只只进进行自行自身身类类型的型的测测评测测评，如管理人，如管理人员员只能只能对对管理人管理人员进员进行行测评测评，教，教师师只能只能测评测评教教师师。项项目名称：网目名称：网络测评络测评系系统统计计划划编编号：号：eval_wh_012日期：日期：*年年*月月*日日记录编记录编号：号：eval_wh_012 评价维护活动评价维护活动缺乏有效的数据就无法评价软件维护活动。缺乏有效的数据就无法评价软件维护活动。如果已经开始保存维护记录，则可以对维护工作做一如果已经开始保存维护记录，则可以对维护工作做一些定量度量，至少可以从如下些定量度量，至少可以从如下7方面进行评价：方面进行评价：每次程序运行平均失败的次数；每次程序运行平均失败的次数；用于每一类维护活动的总人时数；用于每一类维护活动的总人时数；平均每个程序、每种语言、每种维护类型所必需的平均每个程序、每种语言、每种维护类型所必需的程序变动数；程序变动数；维护过程中增加或删除源语句平均花费的人时数；维护过程中增加或删除源语句平均花费的人时数；维护每种语言平均花费的人时数；维护每种语言平均花费的人时数；一张维护要求表的平均周转时间；一张维护要求表的平均周转时间；不同维护类型所占的比例；不同维护类型所占的比例；根据这些统计量可对开发技术、编程语言，以及对维护根据这些统计量可对开发技术、编程语言，以及对维护工作量的预测与资源分配等诸多方面的决策进行评价。工作量的预测与资源分配等诸多方面的决策进行评价。软件可维护性软件可维护性软件可维护性即软件被理解、改正、调软件可维护性即软件被理解、改正、调整和改进的难易程度。整和改进的难易程度。可维护性是指导软件工程各个阶段工作可维护性是指导软件工程各个阶段工作的一条基本原则，也是软件工程追求的的一条基本原则，也是软件工程追求的目标之一。目标之一。影响软件可维护性的因素影响软件可维护性的因素软件的可维护性受各种因素的影响：设计、编码和测试时软件的可维护性受各种因素的影响：设计、编码和测试时漫不经心，软件配置不全，都会给维护带来困难。除了与漫不经心，软件配置不全，都会给维护带来困难。除了与开发方法有关的因素外，还有下列与开发环境有关的因素开发方法有关的因素外，还有下列与开发环境有关的因素:是否拥有一组训练有素的软件人员是否拥有一组训练有素的软件人员;系统结构是否可理解系统结构是否可理解;是否使用标准的程序设计语言是否使用标准的程序设计语言;是否使用标准的操作系统是否使用标准的操作系统;文档的结构是否标准化文档的结构是否标准化;测试用例是否合适测试用例是否合适;是否已有嵌入系统的调试工具是否已有嵌入系统的调试工具;是否有一台计算机可用于维护。是否有一台计算机可用于维护。除此之外，软件开发时的原班人马是否能参加维护也是一除此之外，软件开发时的原班人马是否能参加维护也是一个值得考虑的因素。个值得考虑的因素。软件可维护性的度量软件可维护性的度量软件可维护性与软件质量和可靠性一样是难于软件可维护性与软件质量和可靠性一样是难于量化的概念，然而借助维护活动中可以定量估量化的概念，然而借助维护活动中可以定量估算的属性，能间接地度量可维护性算的属性，能间接地度量可维护性:察觉到问题所耗的时间察觉到问题所耗的时间;收集维护工具所用的时间收集维护工具所用的时间;分析问题所需时间分析问题所需时间;形成修改说明书所需时间；形成修改说明书所需时间；纠错纠错(或修改或修改)所用时间所用时间;局部测试所用时间局部测试所用时间;整体测试所用时间整体测试所用时间;维护复审所用时间维护复审所用时间;完全恢复所用时间。完全恢复所用时间。提高软件可维护性的方法提高软件可维护性的方法 建立明确的软件质量目标和优先级建立明确的软件质量目标和优先级 使用提高软件质量的技术和工具使用提高软件质量的技术和工具 进行明确的质量保证审查进行明确的质量保证审查 选择可维护的程序设计语言选择可维护的程序设计语言 改进程序的文档改进程序的文档 开发软件时考虑到维护开发软件时考虑到维护软件维护的副作用软件维护的副作用软件修改是一项很危险的工作软件修改是一项很危险的工作,对一个复杂的对一个复杂的逻辑过程逻辑过程,那怕做一项微小的改动那怕做一项微小的改动,都可能引入都可能引入潜在的错误潜在的错误,虽然设计文档化和细致的回归测虽然设计文档化和细致的回归测试有助于排除错误试有助于排除错误,但是维护仍然会产生副作但是维护仍然会产生副作用。用。软件维护的副作用指，由于维护或在维护过程软件维护的副作用指，由于维护或在维护过程中其他一些不期望的行为引入的错误中其他一些不期望的行为引入的错误,副作用副作用大致可分为三类大致可分为三类:代码副作用代码副作用数据副作用数据副作用文档副作用文档副作用代码的副作用代码的副作用修改或删除子程序修改或删除子程序;修改或删除语句标号修改或删除语句标号;修改或删除标识符修改或删除标识符;为提高执行效率而做的修改为提高执行效率而做的修改;修改文件的修改文件的open、close操作操作;修改逻辑操作符修改逻辑操作符;由设计变动引起的代码修改由设计变动引起的代码修改;修改对边界条件的测试。修改对边界条件的测试。数据的副作用数据的副作用局部和全局常量的再定义局部和全局常量的再定义;记录或文件格式的再定义记录或文件格式的再定义;增减数据或其他复杂数据结构的体积增减数据或其他复杂数据结构的体积;修改全局数据修改全局数据;重新初始化控制标志和指针重新初始化控制标志和指针;重新排列重新排列I/O表或子程序参数表。表或子程序参数表。文档的副作用文档的副作用维护应维护应统一考虑整个软件配置统一考虑整个软件配置,而不仅仅是源代码。否而不仅仅是源代码。否则则,由于在设计文档和用户手册中未能准确反映修改情由于在设计文档和用户手册中未能准确反映修改情况而引起文档副作用。况而引起文档副作用。对软件的对软件的任何修改都应在相应的技术文档中反映出来任何修改都应在相应的技术文档中反映出来,如果设计文档不能与软件当前的状况对应则比没有文如果设计文档不能与软件当前的状况对应则比没有文档更糟。档更糟。对用户来说对用户来说,若使用若使用说明中未能反映修改后的状况说明中未能反映修改后的状况,那那么用户在这些问题上必定出错。么用户在这些问题上必定出错。一次维护完成之后一次维护完成之后,再次交付软件之前应仔细复审整个再次交付软件之前应仔细复审整个配置配置,有效地减少文档副作用。有效地减少文档副作用。某些维护申请不必修改设计和代码某些维护申请不必修改设计和代码,只需整理用户文档只需整理用户文档便可达到维护的目的。便可达到维护的目的。软件可维护性软件可维护性许多软件的维护十分困难，原因在于这些许多软件的维护十分困难，原因在于这些许多软件的维护十分困难，原因在于这些许多软件的维护十分困难，原因在于这些软件的文档不全、质量差、开发过程不注软件的文档不全、质量差、开发过程不注软件的文档不全、质量差、开发过程不注软件的文档不全、质量差、开发过程不注意采用好的方法，忽视程序设计风格等。意采用好的方法，忽视程序设计风格等。意采用好的方法，忽视程序设计风格等。意采用好的方法，忽视程序设计风格等。许多维护要求并不是因为程序中出错而提许多维护要求并不是因为程序中出错而提许多维护要求并不是因为程序中出错而提许多维护要求并不是因为程序中出错而提出的，而是为适应环境变化或需求变化而出的，而是为适应环境变化或需求变化而出的，而是为适应环境变化或需求变化而出的，而是为适应环境变化或需求变化而提出的。提出的。提出的。提出的。为了使得软件能够易于维护，必须考虑使为了使得软件能够易于维护，必须考虑使为了使得软件能够易于维护，必须考虑使为了使得软件能够易于维护，必须考虑使软件具有可维护性。软件具有可维护性。软件具有可维护性。软件具有可维护性。软件可维护性的定义软件可维护性的定义软件可维护性软件可维护性软件可维护性软件可维护性是指纠正软件系统出现的错误和是指纠正软件系统出现的错误和是指纠正软件系统出现的错误和是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或缺陷，以及为满足新的要求进行修改、扩充或缺陷，以及为满足新的要求进行修改、扩充或缺陷，以及为满足新的要求进行修改、扩充或压缩的压缩的压缩的压缩的容易程度容易程度容易程度容易程度。可维护性、可使用性、可靠性可维护性、可使用性、可靠性可维护性、可使用性、可靠性可维护性、可使用性、可靠性是衡量是衡量是衡量是衡量软件质量软件质量软件质量软件质量的主要质量特性，也是用户十分关心的几个方的主要质量特性，也是用户十分关心的几个方的主要质量特性，也是用户十分关心的几个方的主要质量特性，也是用户十分关心的几个方面。面。面。面。软件的可维护性是软件开发阶段各个时期的关软件的可维护性是软件开发阶段各个时期的关软件的可维护性是软件开发阶段各个时期的关软件的可维护性是软件开发阶段各个时期的关键目标。键目标。键目标。键目标。目前广泛使用的是用如下的七个特性来衡量目前广泛使用的是用如下的七个特性来衡量目前广泛使用的是用如下的七个特性来衡量目前广泛使用的是用如下的七个特性来衡量程序的可维护性。程序的可维护性。程序的可维护性。程序的可维护性。可理解性可理解性可理解性可理解性可使用性可使用性可使用性可使用性可测试性可测试性可测试性可测试性可移植性可移植性可移植性可移植性可修改性可修改性可修改性可修改性效率效率效率效率可靠性可靠性可靠性可靠性而且对于不同类型的维护，这七种特性的侧而且对于不同类型的维护，这七种特性的侧而且对于不同类型的维护，这七种特性的侧而且对于不同类型的维护，这七种特性的侧重点也不相同重点也不相同重点也不相同重点也不相同。在各类维护中的侧重点在各类维护中的侧重点 这些质量特性通常体现在软件产品的许多方这些质量特性通常体现在软件产品的许多方这些质量特性通常体现在软件产品的许多方这些质量特性通常体现在软件产品的许多方面面面面;为使每一个质量特性都达到预定的要求，需为使每一个质量特性都达到预定的要求，需为使每一个质量特性都达到预定的要求，需为使每一个质量特性都达到预定的要求，需要在软件开发的各个阶段采取相应的措施加要在软件开发的各个阶段采取相应的措施加要在软件开发的各个阶段采取相应的措施加要在软件开发的各个阶段采取相应的措施加以保证。以保证。以保证。以保证。这些质量要求要渗透到而各开发阶段的各个这些质量要求要渗透到而各开发阶段的各个这些质量要求要渗透到而各开发阶段的各个这些质量要求要渗透到而各开发阶段的各个步骤当中。因此，软件的可维护性是产品投步骤当中。因此，软件的可维护性是产品投步骤当中。因此，软件的可维护性是产品投步骤当中。因此，软件的可维护性是产品投入运行以前各阶段面向上述各质量特性要求入运行以前各阶段面向上述各质量特性要求入运行以前各阶段面向上述各质量特性要求入运行以前各阶段面向上述各质量特性要求进行开发的最终结果。进行开发的最终结果。进行开发的最终结果。进行开发的最终结果。可维护性的度量可维护性的度量人们一直期望对软件的可维护性做出定量度人们一直期望对软件的可维护性做出定量度人们一直期望对软件的可维护性做出定量度人们一直期望对软件的可维护性做出定量度量，但要做到这一点并不容易。量，但要做到这一点并不容易。量，但要做到这一点并不容易。量，但要做到这一点并不容易。常用的度量一个可维护的程序的七种特性的常用的度量一个可维护的程序的七种特性的常用的度量一个可维护的程序的七种特性的常用的度量一个可维护的程序的七种特性的方法。就是方法。就是方法。就是方法。就是 质量检查表质量检查表质量检查表质量检查表 质量测试质量测试质量测试质量测试 质量标准质量标准质量标准质量标准质量检查表是用于测试程序中某些质量特性是质量检查表是用于测试程序中某些质量特性是质量检查表是用于测试程序中某些质量特性是质量检查表是用于测试程序中某些质量特性是否存在的一个问题清单。否存在的一个问题清单。否存在的一个问题清单。否存在的一个问题清单。评价者针对检查表上的每一个问题，依据自己评价者针对检查表上的每一个问题，依据自己评价者针对检查表上的每一个问题，依据自己评价者针对检查表上的每一个问题，依据自己的定性判断，回答的定性判断，回答的定性判断，回答的定性判断，回答“Yes”“Yes”“Yes”“Yes”或者或者或者或者“No”“No”“No”“No”。质量测试与质量标准则用于定量分析和评价程质量测试与质量标准则用于定量分析和评价程质量测试与质量标准则用于定量分析和评价程质量测试与质量标准则用于定量分析和评价程序的质量。序的质量。序的质量。序的质量。由于许多质量特性是相互抵触的，要考虑几种由于许多质量特性是相互抵触的，要考虑几种由于许多质量特性是相互抵触的，要考虑几种由于许多质量特性是相互抵触的，要考虑几种不同的度量标准，相应地去度量不同的质量特不同的度量标准，相应地去度量不同的质量特不同的度量标准，相应地去度量不同的质量特不同的度量标准，相应地去度量不同的质量特性。性。性。性。1.1.可理解性可理解性可理解性表明人们通过阅读源代码和相关文可理解性表明人们通过阅读源代码和相关文可理解性表明人们通过阅读源代码和相关文可理解性表明人们通过阅读源代码和相关文档，了解程序功能及其如何运行的容易程度。档，了解程序功能及其如何运行的容易程度。档，了解程序功能及其如何运行的容易程度。档，了解程序功能及其如何运行的容易程度。一个可理解的程序应具备以下一些特性：模一个可理解的程序应具备以下一些特性：模一个可理解的程序应具备以下一些特性：模一个可理解的程序应具备以下一些特性：模块化，风格一致性，不使用令人捉摸不定或块化，风格一致性，不使用令人捉摸不定或块化，风格一致性，不使用令人捉摸不定或块化，风格一致性，不使用令人捉摸不定或含糊不清的代码，使用有意义的数据名和过含糊不清的代码，使用有意义的数据名和过含糊不清的代码，使用有意义的数据名和过含糊不清的代码，使用有意义的数据名和过程名，结构化，完整性等。程名，结构化，完整性等。程名，结构化，完整性等。程名，结构化，完整性等。2.2.可靠性可靠性可靠性表明一个程序按照用户的要求和设计可靠性表明一个程序按照用户的要求和设计可靠性表明一个程序按照用户的要求和设计可靠性表明一个程序按照用户的要求和设计目标，在给定的一段时间内正确执行的概率。目标，在给定的一段时间内正确执行的概率。目标，在给定的一段时间内正确执行的概率。目标，在给定的一段时间内正确执行的概率。关于可靠性，度量的标准主要有：关于可靠性，度量的标准主要有：关于可靠性，度量的标准主要有：关于可靠性，度量的标准主要有：平均失效间隔时间平均失效间隔时间平均失效间隔时间平均失效间隔时间MTTFMTTF 平均修复时间平均修复时间平均修复时间平均修复时间MTTRMTTR 有效性有效性有效性有效性A=MTBD/(MTBD+MDT)A=MTBD/(MTBD+MDT)度量可靠性的方法度量可靠性的方法 根据程序错误统计数字，进行可靠性预测。根据程序错误统计数字，进行可靠性预测。根据程序错误统计数字，进行可靠性预测。根据程序错误统计数字，进行可靠性预测。常用常用常用常用方法是利用一些可靠性模型，方法是利用一些可靠性模型，方法是利用一些可靠性模型，方法是利用一些可靠性模型，根据程序测试时发根据程序测试时发根据程序测试时发根据程序测试时发现并排除的错误数预测平均失效间隔时间现并排除的错误数预测平均失效间隔时间现并排除的错误数预测平均失效间隔时间现并排除的错误数预测平均失效间隔时间MTTFMTTF。根据程序复杂性，预测软件可靠性。根据程序复杂性，预测软件可靠性。根据程序复杂性，预测软件可靠性。根据程序复杂性，预测软件可靠性。用程序复杂性预测可靠性，前提条件是可靠性与用程序复杂性预测可靠性，前提条件是可靠性与用程序复杂性预测可靠性，前提条件是可靠性与用程序复杂性预测可靠性，前提条件是可靠性与复杂性有关。因此可用复杂性预测出错率。程序复杂性有关。因此可用复杂性预测出错率。程序复杂性有关。因此可用复杂性预测出错率。程序复杂性有关。因此可用复杂性预测出错率。程序复杂性度量标准可用于预测哪些模块最可能发生复杂性度量标准可用于预测哪些模块最可能发生复杂性度量标准可用于预测哪些模块最可能发生复杂性度量标准可用于预测哪些模块最可能发生错误，以及可能出现的错误类型。错误，以及可能出现的错误类型。错误，以及可能出现的错误类型。错误，以及可能出现的错误类型。3.3.可测试性可测试性可测试性表明论证程序正确性的容易程度。可测试性表明论证程序正确性的容易程度。可测试性表明论证程序正确性的容易程度。可测试性表明论证程序正确性的容易程度。程序越程序越程序越程序越简单，证明其正确性就越容易。而且设计合用的测简单，证明其正确性就越容易。而且设计合用的测简单，证明其正确性就越容易。而且设计合用的测简单，证明其正确性就越容易。而且设计合用的测试用例，取决于对程序的全面理解。试用例，取决于对程序的全面理解。试用例，取决于对程序的全面理解。试用例，取决于对程序的全面理解。一个可测试的程序应当是可理解的，可靠的，简单一个可测试的程序应当是可理解的，可靠的，简单一个可测试的程序应当是可理解的，可靠的，简单一个可测试的程序应当是可理解的，可靠的，简单的。的。的。的。用于可测试性度量的检查项目如下：用于可测试性度量的检查项目如下：用于可测试性度量的检查项目如下：用于可测试性度量的检查项目如下：程序是否模块化程序是否模块化程序是否模块化程序是否模块化?结构是否良好结构是否良好结构是否良好结构是否良好?程序是否可理解程序是否可理解程序是否可理解程序是否可理解?程序是否可靠程序是否可靠程序是否可靠程序是否可靠?程序是否能显示任意中间结果程序是否能显示任意中间结果程序是否能显示任意中间结果程序是否能显示任意中间结果?程序是否能以清楚的方式描述它的输出程序是否能以清楚的方式描述它的输出程序是否能以清楚的方式描述它的输出程序是否能以清楚的方式描述它的输出?程序是否能及时地按照要求显示所有的输入程序是否能及时地按照要求显示所有的输入程序是否能及时地按照要求显示所有的输入程序是否能及时地按照要求显示所有的输入?程序是否有跟踪及显示逻辑控制流程的能力程序是否有跟踪及显示逻辑控制流程的能力程序是否有跟踪及显示逻辑控制流程的能力程序是否有跟踪及显示逻辑控制流程的能力?程序是否能从检查点再启动程序是否能从检查点再启动程序是否能从检查点再启动程序是否能从检查点再启动?程序是否能显示带说明的错误信息程序是否能显示带说明的错误信息程序是否能显示带说明的错误信息程序是否能显示带说明的错误信息?4.4.可修改性可修改性可修改性表明程序容易修改的程度。可修改性表明程序容易修改的程度。可修改性表明程序容易修改的程度。可修改性表明程序容易修改的程度。一个可修改的程序应当是可理解的、通用的、一个可修改的程序应当是可理解的、通用的、一个可修改的程序应当是可理解的、通用的、一个可修改的程序应当是可理解的、通用的、灵活的、简单的。灵活的、简单的。灵活的、简单的。灵活的、简单的。通用性是指程序适用于各种功能变化而无需通用性是指程序适用于各种功能变化而无需通用性是指程序适用于各种功能变化而无需通用性是指程序适用于各种功能变化而无需修改。修改。修改。修改。灵活性是指能够容易地对程序进行修改。灵活性是指能够容易地对程序进行修改。灵活性是指能够容易地对程序进行修改。灵活性是指能够容易地对程序进行修改。测试可修改性的一种定量方法是修改练习。测试可修改性的一种定量方法是修改练习。测试可修改性的一种定量方法是修改练习。测试可修改性的一种定量方法是修改练习。其基本思想是通过做几个简单的修改，来评其基本思想是通过做几个简单的修改，来评其基本思想是通过做几个简单的修改，来评其基本思想是通过做几个简单的修改，来评价修改的难度。价修改的难度。价修改的难度。价修改的难度。设设设设C C是程序中各个模块的平均复杂性，是程序中各个模块的平均复杂性，是程序中各个模块的平均复杂性，是程序中各个模块的平均复杂性，n n是是是是必须修改的模块数，必须修改的模块数，必须修改的模块数，必须修改的模块数，A A 是要修改的模块的平是要修改的模块的平是要修改的模块的平是要修改的模块的平均复杂性。均复杂性。均复杂性。均复杂性。则则则则修改的难度修改的难度修改的难度修改的难度D D由下式计算：由下式计算：由下式计算：由下式计算：D=A/C D=A/C5.5.可移植性可移植性可移植性表明程序转移到一个新的计算环境的可移植性表明程序转移到一个新的计算环境的可移植性表明程序转移到一个新的计算环境的可移植性表明程序转移到一个新的计算环境的可能性的大小。可能性的大小。可能性的大小。可能性的大小。或者它表明程序可以容易地、或者它表明程序可以容易地、或者它表明程序可以容易地、或者它表明程序可以容易地、有效地在各种各样的计算环境中运行的容易程有效地在各种各样的计算环境中运行的容易程有效地在各种各样的计算环境中运行的容易程有效地在各种各样的计算环境中运行的容易程度。度。度。度。一个可移植的程序应具有结构良好、灵活、不一个可移植的程序应具有结构良好、灵活、不一个可移植的程序应具有结构良好、灵活、不一个可移植的程序应具有结构良好、灵活、不依赖于某一具体计算机或操作系统的性能。依赖于某一具体计算机或操作系统的性能。依赖于某一具体计算机或操作系统的性能。依赖于某一具体计算机或操作系统的性能。用于可移植性度量的检查项目如下：用于可移植性度量的检查项目如下：用于可移植性度量的检查项目如下：用于可移植性度量的检查项目如下：是否是用高级的独立于机器的语言来编写程序是否是用高级的独立于机器的语言来编写程序是否是用高级的独立于机器的语言来编写程序是否是用高级的独立于机器的语言来编写程序?是否使用广泛使用的标准化的程序设计语言来是否使用广泛使用的标准化的程序设计语言来是否使用广泛使用的标准化的程序设计语言来是否使用广泛使用的标准化的程序设计语言来编写程序编写程序编写程序编写程序?是否仅使用了这种语言的标准版本是否仅使用了这种语言的标准版本是否仅使用了这种语言的标准版本是否仅使用了这种语言的标准版本和特性和特性和特性和特性?程序中是否使用了标准的普遍使用的库功能和程序中是否使用了标准的普遍使用的库功能和程序中是否使用了标准的普遍使用的库功能和程序中是否使用了标准的普遍使用的库功能和子程序子程序子程序子程序?程序中是否极少使用或根本不使用操作系统的程序中是否极少使用或根本不使用操作系统的程序中是否极少使用或根本不使用操作系统的程序中是否极少使用或根本不使用操作系统的功能功能功能功能?程序在执行之前是否初始化内存程序在执行之前是否初始化内存程序在执行之前是否初始化内存程序在执行之前是否初始化内存?程序在执行之前是否测定当前的输入输出程序在执行之前是否测定当前的输入输出程序在执行之前是否测定当前的输入输出程序在执行之前是否测定当前的输入输出设备设备设备设备?程序是否把与机器相关的语句分离了出来，程序是否把与机器相关的语句分离了出来，程序是否把与机器相关的语句分离了出来，程序是否把与机器相关的语句分离了出来，集中放在了一些单独的程序模块中，并有说集中放在了一些单独的程序模块中，并有说集中放在了一些单独的程序模块中，并有说集中放在了一些单独的程序模块中，并有说明文件明文件明文件明文件?程序是否结构化程序是否结构化程序是否结构化程序是否结构化?并允许在小一些的计算机并允许在小一些的计算机并允许在小一些的计算机并允许在小一些的计算机上分段上分段上分段上分段(覆盖覆盖覆盖覆盖)运行运行运行运行?程序中是否避免了依赖于字母数字或特殊字程序中是否避免了依赖于字母数字或特殊字程序中是否避免了依赖于字母数字或特殊字程序中是否避免了依赖于字母数字或特殊字符的内部位表示符的内部位表示符的内部位表示符的内部位表示?6.6.效率效率效率表明一个程序能执行预定功能而又不浪效率表明一个程序能执行预定功能而又不浪效率表明一个程序能执行预定功能而又不浪效率表明一个程序能执行预定功能而又不浪费机器资源的程度费机器资源的程度费机器资源的程度费机器资源的程度。这些机器资源包括内存容量、外存容量、通这些机器资源包括内存容量、外存容量、通这些机器资源包括内存容量、外存容量、通这些机器资源包括内存容量、外存容量、通道容量和执行时间。道容量和执行时间。道容量和执行时间。道容量和执行时间。用于效率度量的检查项目如下用于效率度量的检查项目如下用于效率度量的检查项目如下用于效率度量的检查项目如下：程序是否模块化程序是否模块化程序是否模块化程序是否模块化?结构是否良好结构是否良好结构是否良好结构是否良好?是否消除了无用的标号与表达式，以充分是否消除了无用的标号与表达式，以充分是否消除了无用的标号与表达式，以充分是否消除了无用的标号与表达式，以充分发挥编译器优化作用发挥编译器优化作用发挥编译器优化作用发挥编译器优化作用?程序的编译器是否有优化功能程序的编译器是否有优化功能程序的编译器是否有优化功能程序的编译器是否有优化功能?是否把特殊子程序和错误处理子程序都是否把特殊子程序和错误处理子程序都是否把特殊子程序和错误处理子程序都是否把特殊子程序和错误处理子程序都归入了单独的模块中归入了单独的模块中归入了单独的模块中归入了单独的模块中?是否以快速的数学运算代替了较慢的数是否以快速的数学运算代替了较慢的数是否以快速的数学运算代替了较慢的数是否以快速的数学运算代替了较慢的数学运算学运算学运算学运算?是否尽可能