软件工程-软件维护课件

第第8 8章章 软件维护软件维护软件维护的基本概念软软软软件件件件维维维维护护护护是是是是指指指指软软软软件件件件系系系系统统统统交交交交付付付付使使使使用用用用以以以以后后后后，为为为为了了了了改改改改正正正正错错错错误误误误或或或或满满满满足新的需求而修改软件的过程。足新的需求而修改软件的过程。足新的需求而修改软件的过程。足新的需求而修改软件的过程。软软件件件件维维护护工工工工作作作作处处于于于于软软件件件件生生生生命命命命期期期期的的的的最最最最后后后后阶阶段段段段，维维护护阶阶段段段段是是是是软软软软件件件件生生生生存存存存期期期期中中中中最最最最长长长长的的的的一一一一个个个个阶阶阶阶段段段段，其其其其费费用用用用高高高高达达达达整整整整个个个个软软件件件件生生生生命命命命期期期期花花花花费费的的的的约约60%-7060%-70。生生生生 命命命命 周周周周 期期期期工工工工 程程程程 周周周周 期期期期运运运运 行行行行 维维维维 护护护护 周周周周 期期期期完善性维护完善性维护完善性维护完善性维护（Perfective MaintenancePerfective Maintenance）纠错性维护纠错性维护纠错性维护纠错性维护（Corrective MaintenanceCorrective Maintenance）适应性维护适应性维护适应性维护适应性维护（Adaptive MaintenanceAdaptive Maintenance）预防性维护预防性维护预防性维护预防性维护（Preventive MaintenancePreventive Maintenance）按照不同的维护目的，维护工作可分成按照不同的维护目的，维护工作可分成按照不同的维护目的，维护工作可分成按照不同的维护目的，维护工作可分成4 4 4 4类。类。类。类。软件维护的类型完善性维护完善性维护完善性维护完善性维护（Perfective MaintenancePerfective Maintenance）纠错性维护纠错性维护纠错性维护纠错性维护（Corrective MaintenanceCorrective Maintenance）适应性维护适应性维护适应性维护适应性维护（Adaptive MaintenanceAdaptive Maintenance）预防性维护预防性维护预防性维护预防性维护（Preventive MaintenancePreventive Maintenance）按照不同的维护目的，维护工作可分成按照不同的维护目的，维护工作可分成按照不同的维护目的，维护工作可分成按照不同的维护目的，维护工作可分成4 4 4 4类。类。类。类。软件维护的类型扩扩扩扩充充充充原原原原有有有有系系系系统统统统的的的的功功功功能能能能，提提提提高高高高系系系系统统统统的的的的性性性性能能能能，提提提提高高高高软软软软件件件件运运运运行行行行的的的的效效效效率率率率，满满满满足足足足用用用用户户户户的的的的实实实实际需要而进行的维护活动。际需要而进行的维护活动。际需要而进行的维护活动。际需要而进行的维护活动。当当一一个个软件件系系统投投入入使使用用和和成成功功地地运运行行时，用用户会会根根据据业务发展展的的实际需需要要，提提出出增增加加新新功功能能、修修改改已已有有功功能能以以及及性性能能的改的改进要求等。要求等。完善性维护完善性维护完善性维护完善性维护（Perfective MaintenancePerfective Maintenance）纠错性维护纠错性维护纠错性维护纠错性维护（Corrective MaintenanceCorrective Maintenance）适应性维护适应性维护适应性维护适应性维护（Adaptive MaintenanceAdaptive Maintenance）预防性维护预防性维护预防性维护预防性维护（Preventive MaintenancePreventive Maintenance）按照不同的维护目的，维护工作可分成按照不同的维护目的，维护工作可分成按照不同的维护目的，维护工作可分成按照不同的维护目的，维护工作可分成4 4 4 4类。类。类。类。软件维护的类型软件件测试不不可可能能找找出出一一个个软件件系系统中中所所有有潜潜伏伏的的错误，所所以以当当软件件在在特特定定情情况况下下运运行行时，这些些潜潜伏伏的的错误可可能能会会暴暴露露出出来来。对对在在测测试试阶阶段段未未能能发发现现的的，在在软软件件投投入入使使用用后后才才逐逐渐渐暴暴露露出出来来的的错错误误的的测测试试、诊诊断断、定定位位、纠纠错错以以及及验验证证、修修改改的的回回归归测测试试过过程程，称为称为纠错性性维护。完善性维护完善性维护完善性维护完善性维护（Perfective MaintenancePerfective Maintenance）纠错性维护纠错性维护纠错性维护纠错性维护（Corrective MaintenanceCorrective Maintenance）适应性维护适应性维护适应性维护适应性维护（Adaptive MaintenanceAdaptive Maintenance）预防性维护预防性维护预防性维护预防性维护（Preventive MaintenancePreventive Maintenance）按照不同的维护目的，维护工作可分成按照不同的维护目的，维护工作可分成按照不同的维护目的，维护工作可分成按照不同的维护目的，维护工作可分成4 4 4 4类。类。类。类。软件维护的类型计计算算机机的的软软、硬硬件件环环境境，数数据据环环境境在在不不断断的的变变化化，使使运运行行的的软软件件能能适适应应运运行行环环境境或或者者数数据据的的变变动动而而修改软件的过程称为适宜性维护。修改软件的过程称为适宜性维护。完善性维护完善性维护完善性维护完善性维护（Perfective MaintenancePerfective Maintenance）纠错性维护纠错性维护纠错性维护纠错性维护（Corrective MaintenanceCorrective Maintenance）适应性维护适应性维护适应性维护适应性维护（Adaptive MaintenanceAdaptive Maintenance）预防性维护预防性维护预防性维护预防性维护（Preventive MaintenancePreventive Maintenance）按照不同的维护目的，维护工作可分成按照不同的维护目的，维护工作可分成按照不同的维护目的，维护工作可分成按照不同的维护目的，维护工作可分成4 4 4 4类。类。类。类。软件维护的类型为为了了进进一一步步改改善善软软件件的的可可靠靠性性和和易易维维护护性性，或或者者为为预预见见的的将将来来软软件件运运行行和和维维护护打下更好的基础而打下更好的基础而对软件对软件进行修改。进行修改。由由于于对对于于该该类类维维护护工工作作必必须须采采用用先先进进的的软软件件工工程程方方法法，对对需需要要修修改改的的软软件件或或部部分分进进行行设设计计、编编码码和和测测试试。对对该该类类维维护护工工作的必要性有争议，它所占的比例较小。作的必要性有争议，它所占的比例较小。纠错性维护纠错性维护适应性维护适应性维护完善性维护完善性维护预防性维护预防性维护纠错性维纠错性维纠错性维纠错性维纠错性维纠错性维护护护护护护25%25%25%25%25%25%适应性适应性维护维护21%完善性完善性完善性完善性维护维护维护维护50%50%预防性预防性预防性预防性维护维护维护维护4%4%各类维护所占的比例各类维护所占的比例各类维护所占的比例各类维护所占的比例针针对对以以上上几几种种类类型型的的维维护护，可可采采取取相相应应的的维维护护策策略略，以以提提高高维维护护效效率率，降降低低维维护护成成本本。图图中中表表示示各各种种维维护护所所占占的的比比例例，显然显然完善性维护完善性维护完善性维护完善性维护所占的比例最大。所占的比例最大。软件维护策略软件维护的策略软件维护的策略软件维护的特性一、时间长、工作量大、成本高一、时间长、工作量大、成本高一、时间长、工作量大、成本高一、时间长、工作量大、成本高维护阶段段是是软软件件生生存存期期中中最最长长的的一一个个阶阶段段，软软件件维维护护的的工工作作量量占占整整个个软软件生存期的件生存期的70以上，而且还在逐年增加。以上，而且还在逐年增加。二、维护的副作用二、维护的副作用二、维护的副作用二、维护的副作用维维护护的的副副作作用用是是指指由由于于修修改改程程序序而而导导致致新新的的错错误误或或者者新新增增加加一一些些不不必必要的活动。要的活动。、修改代码的副作用、修改代码的副作用在修改源代码时，可能引起的错误。在修改源代码时，可能引起的错误。、修改数据的副作用、修改数据的副作用在在修修改改数数据据结结构构时时，有有可可能能造造成成软软件件设设计计与与数数据据结结构构不不匹匹配配，因因而而导导致致软件出错。数据副作用就是修改软件信息结构导致的结果。软件出错。数据副作用就是修改软件信息结构导致的结果。、修改文档的副作用、修改文档的副作用对对软软件件的的数数据据流流、软软件件结结构构、模模块块逻逻辑辑等等进进行行修修改改时时，必必须须对对相相关关技技术术文文档档进进行行相相应应修修改改。但但修修改改文文档档过过程程会会产产生生新新的的错错误误，导导致致文文档档与与程程序序功功能能不不匹匹配，缺省条件改变等错误，产生文档的副作用。配，缺省条件改变等错误，产生文档的副作用。三、软件维护的困难三、软件维护的困难由由于于软软件件维维护护工工作作通通常常并并不不由由软软件件的的设设计计和和开开发发人人员员来来完完成成，维维护护人人员员首首先先要要对对软软件件各各阶阶段段的的文文档档和和代代码码进进行行分分析析、理理解解。因因而而出出现现了了理理解解别别人人的的程程序序困困难难、文文档档不不齐齐等等问问题题，尤尤其其是是对对大大型型、复复杂杂系系统统的的维维护护，更更加加困难和复杂，甚至是不可能的！困难和复杂，甚至是不可能的！结构化维护与非结构化维护结构化维护与非结构化维护非非结结构构化化维维护护 缺缺乏乏必必要要的的文文档档说说明明，文文档档缺缺少少或或者者不不一一制制，难难于于确确定定数数据据结结构构、系系统统接接口口等等特特性性，这这样的维护工作令人生畏，事倍功半。样的维护工作令人生畏，事倍功半。太累了！受不了啦！几万行程序怎么改哦？结结构构化化维维护护 指指软软件件开开发发过过程程是是按按照照软软件件工工程程方方法法进进行行的的，开开发发各各阶阶段段的的文文档档齐齐全全，软软件件的的维维护护过过程程，有一整套完整的方案、技术、审定过程及文档。有一整套完整的方案、技术、审定过程及文档。可可以以看看到到，维维护护工工作作的的难难度度及及工工作作量量的的大大小小，明明显显与与前前期期的的开开发发工工作作密密切相关。切相关。软件维护的困难软件维护的特性软件维护的工作量模型维护活动分为生产性活动和非生产性活动。维护活动分为生产性活动和非生产性活动。生产性活动生产性活动生产性活动生产性活动包括分析评价、修改设计和编写程序代码等。包括分析评价、修改设计和编写程序代码等。非非非非生生生生产产产产性性性性活活活活动动动动包包括括理理解解程程序序代代码码，解解释释数数据据结结构构，接接口口特特点点和和设设计计约约束等。束等。Belady 和和 Lehman提出软件维护工作模型：提出软件维护工作模型：M=P+K*EXP（C-D）其中：其中：M维护工作的总工作量维护工作的总工作量P生产性活动的工作量生产性活动的工作量K经验常数经验常数C程序复杂度（由非结构化维护引起的）程序复杂度（由非结构化维护引起的）D对维护软件熟悉程度的度量对维护软件熟悉程度的度量显显然然，若若越越大大，越越小小，则则维维护护工工作作量量成成指指数数增增长长，为为此此，必必须须防止出现非结构化维护并尽可能由熟悉软件的原开发人员参加维护。防止出现非结构化维护并尽可能由熟悉软件的原开发人员参加维护。软件维护的工作量模型软件维护的工作量模型软件维护的过程软件维护的过程 软软软软件件件件维维维维护护护护是是是是一一一一件件件件复复复复杂杂杂杂而而而而困困困困难难难难的的的的事事事事，必必必必须须须须在在在在相相相相应的技术指导下，按照一定的步骤进行。应的技术指导下，按照一定的步骤进行。应的技术指导下，按照一定的步骤进行。应的技术指导下，按照一定的步骤进行。组织组织组织组织 流程流程流程流程 管理管理管理管理维护组织下图给出了一种典型的维护组织方式。下图给出了一种典型的维护组织方式。维护申请维护管理员系统管理员维护人员配置管理员修改批准人员软件系统软件维护组织其中，维护管理员可以是某个人，也可以是一个包括管理其中，维护管理员可以是某个人，也可以是一个包括管理人员、高级技术人员等在内的小组。人员、高级技术人员等在内的小组。用户用户维护人员维护人员确认维确认维护类型护类型维护实施维护实施评价优评价优先级先级进行问进行问题分析题分析复审复审评价错误评价错误严重程度严重程度进行问进行问题分析题分析确定更确定更改要求改要求维护维护要求要求完完美美性性适适应应性性将安排好的工作将安排好的工作量列入计划量列入计划低低高高纠错性纠错性严重严重不严重不严重安排改正安排改正性维护性维护将改正错误列入计划将改正错误列入计划人人员员安安排排交付使用交付使用的软件的软件理解分析程序理解分析程序安排计划安排计划修改程序修改程序测试程序测试程序 软件维护的工作流程图软件维护的工作流程图软件维护的工作流程图软件维护的工作流程图修改过修改过的软件的软件维护工作的流程下下图图描描述述了了实实施施软软件件维维护护的的工工作作流流程程，一一个个维维护护申申请请经经过过评评审审后后，首首先先要要确确定定维维护护的的类类型型，还还要要分分辨辨错错误误的的严严重重程程度度或或修修改改优优先先级级的的高高低低，分分别处理。别处理。人人员员安安排排维护工作的组织管理软软软软件件件件维维维维护护护护工工工工作作作作不不不不仅仅仅仅是是是是技技技技术术术术性性性性的的的的，它它它它还还还还需需需需要要要要大大大大量量量量的的的的管管管管理理理理工工工工作作作作与与与与之之之之相相相相配配配配合合合合，才才才才能能能能保保保保证证证证维维维维护护护护工工工工作作作作的的的的质质质质量量量量。下下下下图图图图描描描描述述述述了了了了软软软软件件件件维维维维护护护护的管理流程。的管理流程。的管理流程。的管理流程。NYNYYN 软件维护的管理流程软件维护的管理流程软件维护的管理流程软件维护的管理流程 许多软件的维护十分困难，原因在于这些软件的文档不许多软件的维护十分困难，原因在于这些软件的文档不许多软件的维护十分困难，原因在于这些软件的文档不许多软件的维护十分困难，原因在于这些软件的文档不全、质量差、开发过程不注意采用好的方法，忽视程序全、质量差、开发过程不注意采用好的方法，忽视程序全、质量差、开发过程不注意采用好的方法，忽视程序全、质量差、开发过程不注意采用好的方法，忽视程序设计风格等。设计风格等。设计风格等。设计风格等。许多维护要求并不是因为程序中出错而提出的，而是为许多维护要求并不是因为程序中出错而提出的，而是为许多维护要求并不是因为程序中出错而提出的，而是为许多维护要求并不是因为程序中出错而提出的，而是为适应环境变化或需求变化而提出的。适应环境变化或需求变化而提出的。适应环境变化或需求变化而提出的。适应环境变化或需求变化而提出的。为了使得软件能够易于维护，必须考虑使软件具有可维为了使得软件能够易于维护，必须考虑使软件具有可维为了使得软件能够易于维护，必须考虑使软件具有可维为了使得软件能够易于维护，必须考虑使软件具有可维护性护性护性护性软件可维护性的定义软件可维护性的定义软件可维护性软件可维护性软件可维护性软件可维护性是指是指是指是指纠正软件系统出现的错误和缺陷，以及为满纠正软件系统出现的错误和缺陷，以及为满纠正软件系统出现的错误和缺陷，以及为满纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度足新的要求进行修改、扩充或压缩的容易程度足新的要求进行修改、扩充或压缩的容易程度足新的要求进行修改、扩充或压缩的容易程度。可维护性可维护性可维护性可维护性、可使用性可使用性可使用性可使用性、可靠性可靠性可靠性可靠性是衡量软件质量的主要质量特性，是衡量软件质量的主要质量特性，是衡量软件质量的主要质量特性，是衡量软件质量的主要质量特性，也是用户十分关心的几个方面也是用户十分关心的几个方面也是用户十分关心的几个方面也是用户十分关心的几个方面。软件的软件的软件的软件的可维护性可维护性可维护性可维护性是是是是软件开发阶段各个时期的关键目标软件开发阶段各个时期的关键目标软件开发阶段各个时期的关键目标软件开发阶段各个时期的关键目标。软件可维护性软件可维护性目前广泛使用的是用如下的七个特性来衡量程序的可维护目前广泛使用的是用如下的七个特性来衡量程序的可维护目前广泛使用的是用如下的七个特性来衡量程序的可维护目前广泛使用的是用如下的七个特性来衡量程序的可维护性。性。性。性。可理解性可理解性可理解性可理解性可使用性可使用性可使用性可使用性可测试性可测试性可测试性可测试性可移植性可移植性可移植性可移植性可修改性可修改性可修改性可修改性效率效率效率效率可靠性可靠性可靠性可靠性n n而且对于不同类型的维护，这七种特性的侧重点也不相同而且对于不同类型的维护，这七种特性的侧重点也不相同而且对于不同类型的维护，这七种特性的侧重点也不相同而且对于不同类型的维护，这七种特性的侧重点也不相同。表表表表 各类维护中的侧重点各类维护中的侧重点各类维护中的侧重点各类维护中的侧重点改正性维护改正性维护改正性维护改正性维护适应性维护适应性维护适应性维护适应性维护完善性维护完善性维护完善性维护完善性维护可理解性可理解性可理解性可理解性 可测试性可测试性可测试性可测试性 可修改性可修改性可修改性可修改性 可靠性可靠性可靠性可靠性 可移植性可移植性可移植性可移植性 可使用性可使用性可使用性可使用性 效率效率效率效率 这些质量特性通常体现在软件产品的许多这些质量特性通常体现在软件产品的许多方面方面;为使每一个质量特性都达到预定的要求，为使每一个质量特性都达到预定的要求，需要在软件开发的各个阶段采取相应的需要在软件开发的各个阶段采取相应的措施加以保证。措施加以保证。这些质量要求要渗透到而各开发阶段的各这些质量要求要渗透到而各开发阶段的各个步骤当中个步骤当中。因此，软件的可维护性是。因此，软件的可维护性是产品投入运行以前各阶段面向上述各质产品投入运行以前各阶段面向上述各质量特性要求进行开发的最终结果。量特性要求进行开发的最终结果。可维护性的度量质质量量检检查查表表是是用用于于测测试试程程序序中中某某些些质质量量特特性性是是否否存存在在的的一一个个问问题题清清单单。评评测测者者针针对对检检查查表表上上的的每每一一个个问问题题，依依据据自自己己的的定定性性判判断断，回回答答“YesYes”或者或者“NoNo”。质质量量测测试试和和质质量量标标准准用用于于定定量量分分析析和和评评价价程程序序的的质质量量。由由于于许许多多质质量特性是相互抵触的，可用以下度量标准，去度量不同的质量特性。量特性是相互抵触的，可用以下度量标准，去度量不同的质量特性。可维护性可维护性可理解性可理解性可理解性可理解性可靠性可靠性可靠性可靠性可测试性可测试性可测试性可测试性可修改性可修改性可修改性可修改性可移植性可移植性可移植性可移植性可使用性可使用性可使用性可使用性效率效率效率效率可维护性的度量标准可维护性的度量标准可维护性的度量标准可维护性的度量标准可理解性可理解性可理解性可理解性文档化；文档化；模块化；模块化；“90-1090-10测测试试法法”：Shneiderman提提出出一一种种的的一一种种衡衡量量维维护护可可理理解解性性的的方方法法，即即让让有有经经验验的的程程序序员员阅阅读读10分分钟钟要要测测试试的的程程序序，然然后后如如能能凭凭记记忆忆和和理理解写出解写出90的程序，则称该程序是可理解的。的程序，则称该程序是可理解的。可靠性可靠性可靠性可靠性度量的主要标准有：平均失效间隔时间、平均修复时间、有效性。度量的主要标准有：平均失效间隔时间、平均修复时间、有效性。植入模型：根据程序错误统计数字，进行可靠性预测。植入模型：根据程序错误统计数字，进行可靠性预测。根据程序文本复杂性，预测软件可靠性。根据程序文本复杂性，预测软件可靠性。可测试性可测试性可测试性可测试性表表明明论论证证软软件件正正确确性性的的容容易易程程度度。对对于于程程序序模模块块，可可用用程程序序复复杂杂性性来来度量可测试性。度量可测试性。可维护性的度量1可维护性的度量可修改性可修改性可修改性可修改性一个可修改的软件应当是可理解的、通用的、灵活的、简单的。一个可修改的软件应当是可理解的、通用的、灵活的、简单的。一个可修改的软件应当是可理解的、通用的、灵活的、简单的。一个可修改的软件应当是可理解的、通用的、灵活的、简单的。测测测测试试试试可可可可修修修修改改改改性性性性的的的的一一一一种种种种定定定定量量量量方方方方法法法法是是是是修修修修改改改改练练练练习习习习，其其其其基基基基本本本本思思思思想想想想是是是是通通通通过过过过做做做做几几几几个个个个简简简简单的修改，来评价修改难度：单的修改，来评价修改难度：单的修改，来评价修改难度：单的修改，来评价修改难度：D=A*D=A*nn/C/C 其其其其中中中中C C是是是是程程程程序序序序中中中中各各各各个个个个模模模模块块块块的的的的平平平平均均均均复复复复杂杂杂杂性性性性，A A是是是是要要要要修修修修改改改改的的的的n n个个个个模模模模块块块块的的的的平平平平均均均均复复复复杂性。杂性。杂性。杂性。A A和和和和C C可用任何一种度量程序复杂性的方法计算。可用任何一种度量程序复杂性的方法计算。可用任何一种度量程序复杂性的方法计算。可用任何一种度量程序复杂性的方法计算。可移植性可移植性可移植性可移植性表表表表明明明明软软软软件件件件转转转转移移移移到到到到一一一一个个个个新新新新的的的的计计计计算算算算环环环环境境境境的的的的可可可可能能能能性性性性的的的的大大大大小小小小；或或或或者者者者软软软软件件件件能能能能有有有有效效效效地地地地在各种环境中运行的容易程度。在各种环境中运行的容易程度。在各种环境中运行的容易程度。在各种环境中运行的容易程度。效率效率效率效率包括时间和空间的效率。包括时间和空间的效率。包括时间和空间的效率。包括时间和空间的效率。可使用性可使用性可使用性可使用性从从从从用用用用户户户户的的的的角角角角度度度度出出出出发发发发，将将将将可可可可使使使使用用用用性性性性定定定定义义义义为为为为程程程程序序序序方方方方便便便便、实实实实用用用用及及及及易易易易于于于于使使使使用用用用的的的的程程程程度。度。度。度。可维护性的度量提高可维护性的方法提高可维护性的方法提提提提高高高高软软软软件件件件系系系系统统统统的的的的可可可可维维维维护护护护性性性性，并并并并不不不不是是是是维维维维护护护护阶阶阶阶段段段段才才才才进进进进行行行行的的的的过过过过程程程程，而而而而是贯穿于整个软件分析、开发实现的全过程是贯穿于整个软件分析、开发实现的全过程是贯穿于整个软件分析、开发实现的全过程是贯穿于整个软件分析、开发实现的全过程：建立明确的软件质量目标建立明确的软件质量目标使用提高软件质量的技术和工具使用提高软件质量的技术和工具进行明确的质量保证审查进行明确的质量保证审查选择可维护的程序设计语言选择可维护的程序设计语言改进程序的文档改进程序的文档 建立明确的软件质量目标和优先级一个可维护的程序应是一个可维护的程序应是一个可维护的程序应是一个可维护的程序应是可理解的可理解的可理解的可理解的、可靠的可靠的可靠的可靠的、可测试的可测试的可测试的可测试的、可修改可修改可修改可修改的的的的、可移植的可移植的可移植的可移植的、效率高的效率高的效率高的效率高的、可使用的可使用的可使用的可使用的。要实现这所有的目标，需要付出很大的代价，而且也不一定行要实现这所有的目标，需要付出很大的代价，而且也不一定行要实现这所有的目标，需要付出很大的代价，而且也不一定行要实现这所有的目标，需要付出很大的代价，而且也不一定行得通。得通。得通。得通。某些质量特性是相互促进的某些质量特性是相互促进的某些质量特性是相互促进的某些质量特性是相互促进的，例如可理解性和可测试性、可理，例如可理解性和可测试性、可理，例如可理解性和可测试性、可理，例如可理解性和可测试性、可理解性和可修改性。解性和可修改性。解性和可修改性。解性和可修改性。另一些质量特性是相互抵触的另一些质量特性是相互抵触的另一些质量特性是相互抵触的另一些质量特性是相互抵触的，如效率和可移植性、效率和，如效率和可移植性、效率和，如效率和可移植性、效率和，如效率和可移植性、效率和可修改性等。可修改性等。可修改性等。可修改性等。每一种每一种每一种每一种质量特性质量特性质量特性质量特性的的的的相对重要性相对重要性相对重要性相对重要性应随程序的用途及计算环境的应随程序的用途及计算环境的应随程序的用途及计算环境的应随程序的用途及计算环境的不同而不同。例如，对编译程序来说，可能强调效率；但对不同而不同。例如，对编译程序来说，可能强调效率；但对不同而不同。例如，对编译程序来说，可能强调效率；但对不同而不同。例如，对编译程序来说，可能强调效率；但对管理管理管理管理信息系统来说，则可能强调可使用性和可修改性。信息系统来说，则可能强调可使用性和可修改性。信息系统来说，则可能强调可使用性和可修改性。信息系统来说，则可能强调可使用性和可修改性。应当对程序的质量特性，在应当对程序的质量特性，在应当对程序的质量特性，在应当对程序的质量特性，在提出目标提出目标提出目标提出目标的同时还必须的同时还必须的同时还必须的同时还必须规定它们规定它们规定它们规定它们的优先级的优先级的优先级的优先级。使用提高软件质量的技术和工具模块化模块化模块化模块化 如果需要改变某个模块的功能，则只要改变这如果需要改变某个模块的功能，则只要改变这如果需要改变某个模块的功能，则只要改变这如果需要改变某个模块的功能，则只要改变这个模块，对其它模块影响很小；个模块，对其它模块影响很小；个模块，对其它模块影响很小；个模块，对其它模块影响很小；如果需要增加程序的某些功能，则仅需增加完如果需要增加程序的某些功能，则仅需增加完如果需要增加程序的某些功能，则仅需增加完如果需要增加程序的某些功能，则仅需增加完成这些功能的新的模块或模块层；成这些功能的新的模块或模块层；成这些功能的新的模块或模块层；成这些功能的新的模块或模块层；程序的测试与重复测试比较容易；程序的测试与重复测试比较容易；程序的测试与重复测试比较容易；程序的测试与重复测试比较容易；程序错误易于定位和纠正程序错误易于定位和纠正程序错误易于定位和纠正程序错误易于定位和纠正结构化程序设计结构化程序设计 程序被划分成分层的模块结构；程序被划分成分层的模块结构；程序被划分成分层的模块结构；程序被划分成分层的模块结构；模块调用控制必须从模块的入口点进入，从出口点退出。模块调用控制必须从模块的入口点进入，从出口点退出。模块调用控制必须从模块的入口点进入，从出口点退出。模块调用控制必须从模块的入口点进入，从出口点退出。模块的控制结构仅限于顺序、选择、重复三种，且没有模块的控制结构仅限于顺序、选择、重复三种，且没有模块的控制结构仅限于顺序、选择、重复三种，且没有模块的控制结构仅限于顺序、选择、重复三种，且没有GOTOGOTOGOTOGOTO语句。语句。语句。语句。每个程序变量只用于唯一的程序目的，而且变量的作用范每个程序变量只用于唯一的程序目的，而且变量的作用范每个程序变量只用于唯一的程序目的，而且变量的作用范每个程序变量只用于唯一的程序目的，而且变量的作用范围应是明确的、有限制的。围应是明确的、有限制的。围应是明确的、有限制的。围应是明确的、有限制的。用结构化程序设计技术，提高现有系统的可维护性用结构化程序设计技术，提高现有系统的可维护性用结构化程序设计技术，提高现有系统的可维护性用结构化程序设计技术，提高现有系统的可维护性 采用备用件的方法采用备用件的方法采用备用件的方法采用备用件的方法用一个新的结构良好的模块替换掉整用一个新的结构良好的模块替换掉整用一个新的结构良好的模块替换掉整用一个新的结构良好的模块替换掉整个要修改的模块。个要修改的模块。个要修改的模块。个要修改的模块。采用自动重建结构和重新格式化的工具采用自动重建结构和重新格式化的工具采用自动重建结构和重新格式化的工具采用自动重建结构和重新格式化的工具(结构更新技术结构更新技术结构更新技术结构更新技术)把非结构化代码转换成良好结构代码把非结构化代码转换成良好结构代码把非结构化代码转换成良好结构代码把非结构化代码转换成良好结构代码 。改进现有程序不完善的文档改进现有程序不完善的文档改进现有程序不完善的文档改进现有程序不完善的文档建立或补充系统说明书、建立或补充系统说明书、建立或补充系统说明书、建立或补充系统说明书、设计文档、模块说明书、以及在源程序中插入必要注释。设计文档、模块说明书、以及在源程序中插入必要注释。设计文档、模块说明书、以及在源程序中插入必要注释。设计文档、模块说明书、以及在源程序中插入必要注释。进行明确的质量保证审查进行明确的质量保证审查进行明确的质量保证审查进行明确的质量保证审查质量保证审查质量保证审查质量保证审查质量保证审查对于对于对于对于获得和维持软件的质量获得和维持软件的质量获得和维持软件的质量获得和维持软件的质量，是一个很有用的，是一个很有用的，是一个很有用的，是一个很有用的技术。技术。技术。技术。审查审查审查审查可以用来可以用来可以用来可以用来检测在开发和维护阶段内发生的质量变化检测在开发和维护阶段内发生的质量变化检测在开发和维护阶段内发生的质量变化检测在开发和维护阶段内发生的质量变化。一旦检测出问题来，就可以采取措施来纠正，以控制不断增一旦检测出问题来，就可以采取措施来纠正，以控制不断增一旦检测出问题来，就可以采取措施来纠正，以控制不断增一旦检测出问题来，就可以采取措施来纠正，以控制不断增长的软件维护成本，延长软件系统的有效生命期。长的软件维护成本，延长软件系统的有效生命期。长的软件维护成本，延长软件系统的有效生命期。长的软件维护成本，延长软件系统的有效生命期。软件开发期间各个检查点的检查重点软件开发期间各个检查点的检查重点软件开发期间各个检查点的检查重点软件开发期间各个检查点的检查重点 在设计阶段，检查重点是可理解性、可修改性、可测试性。在设计阶段，检查重点是可理解性、可修改性、可测试性。在设计阶段，检查重点是可理解性、可修改性、可测试性。在设计阶段，检查重点是可理解性、可修改性、可测试性。可理解性检查的重点是程序的复杂性。对每个模块可用可理解性检查的重点是程序的复杂性。对每个模块可用可理解性检查的重点是程序的复杂性。对每个模块可用可理解性检查的重点是程序的复杂性。对每个模块可用McCabeMcCabeMcCabeMcCabe环路来计算模块复杂性，若大于环路来计算模块复杂性，若大于环路来计算模块复杂性，若大于环路来计算模块复杂性，若大于10101010，则需重新设计。，则需重新设计。，则需重新设计。，则需重新设计。可以用各种质量特性检查表，或用度量标准来检查可维护性。可以用各种质量特性检查表，或用度量标准来检查可维护性。可以用各种质量特性检查表，或用度量标准来检查可维护性。可以用各种质量特性检查表，或用度量标准来检查可维护性。审查小组可以采用人工测试一类的方式，进行审查。审查小组可以采用人工测试一类的方式，进行审查。审查小组可以采用人工测试一类的方式，进行审查。审查小组可以采用人工测试一类的方式，进行审查。2.2.验收检查验收检查验收检查验收检查验收检查验收检查验收检查验收检查是一个是一个是一个是一个特殊的检查点特殊的检查点特殊的检查点特殊的检查点的检查，是交付使用的检查，是交付使用的检查，是交付使用的检查，是交付使用前的前的前的前的最后一次检查最后一次检查最后一次检查最后一次检查，验收检查验收检查验收检查验收检查实际上是实际上是实际上是实际上是验收测试验收测试验收测试验收测试的一部分，只不过它是的一部分，只不过它是的一部分，只不过它是的一部分，只不过它是从维护的角度提出验收的条件和标准。从维护的角度提出验收的条件和标准。从维护的角度提出验收的条件和标准。从维护的角度提出验收的条件和标准。验收检查必须遵循的最小验收标准。验收检查必须遵循的最小验收标准。验收检查必须遵循的最小验收标准。验收检查必须遵循的最小验收标准。(1)(1)需求和规范标准需求和规范标准需求和规范标准需求和规范标准 需求应当以可测试的术语进行书写，排列优先次序和需求应当以可测试的术语进行书写，排列优先次序和需求应当以可测试的术语进行书写，排列优先次序和需求应当以可测试的术语进行书写，排列优先次序和定义；定义；定义；定义；区分必须的、任选的、将来的需求；区分必须的、任选的、将来的需求；区分必须的、任选的、将来的需求；区分必须的、任选的、将来的需求；包括对系统运行时的计算机设备的需求；对维护、测包括对系统运行时的计算机设备的需求；对维护、测包括对系统运行时的计算机设备的需求；对维护、测包括对系统运行时的计算机设备的需求；对维护、测试、操作、以及维护人员的需求；对测试工具等的需求。试、操作、以及维护人员的需求；对测试工具等的需求。试、操作、以及维护人员的需求；对测试工具等的需求。试、操作、以及维护人员的需求；对测试工具等的需求。(2)(2)设计标准设计标准设计标准设计标准 程序应设计成分层的模块结构。每个模块应程序应设计成分层的模块结构。每个模块应程序应设计成分层的模块结构。每个模块应程序应设计成分层的模块结构。每个模块应完成唯一的功能，并达到高内聚、低耦合；完成唯一的功能，并达到高内聚、低耦合；完成唯一的功能，并达到高内聚、低耦合；完成唯一的功能，并达到高内聚、低耦合；通过一些知道预期变化的实例，说明设计的通过一些知道预期变化的实例，说明设计的通过一些知道预期变化的实例，说明设计的通过一些知道预期变化的实例，说明设计的可扩充性、可缩减性和可适应性。可扩充性、可缩减性和可适应性。可扩充性、可缩减性和可适应性。可扩充性、可缩减性和可适应性。(3)(3)源代码标准源代码标准源代码标准源代码标准 尽可能使用最高级的程序设计语言，且只使尽可能使用最高级的程序设计语言，且只使尽可能使用最高级的程序设计语言，且只使尽可能使用最高级的程序设计语言，且只使用语言的标准版本；用语言的标准版本；用语言的标准版本；用语言的标准版本；所有的代码都必须具有良好的结构；所有的代码都必须具有良好的结构；所有的代码都必须具有良好的结构；所有的代码都必须具有良好的结构；所有的代码都必须文档化，在注释中说明它所有的代码都必须文档化，在注释中说明它所有的代码都必须文档化，在注释中说明它所有的代码都必须文档化，在注释中说明它的输入、输出、以及便于测试再测试的一些特点的输入、输出、以及便于测试再测试的一些特点的输入、输出、以及便于测试再测试的一些特点的输入、输出、以及便于测试再测试的一些特点与风格。与风格。与风格。与风格。(4)(4)文档标准文档标准文档标准文档标准文档中应说明文档中应说明文档中应说明文档中应说明 程序的输入输出程序的输入输出程序的输入输出程序的输入输出 使用的方法使用的方法使用的方法使用的方法算法算法算法算法 错误恢复方法错误恢复方法错误恢复方法错误恢复方法 所有参数的范围所有参数的范围所有参数的范围所有参数的范围 缺省条件等。缺省条件等。缺省条件等。缺省条件等。3.周期性地维护审查 检查点复查检查点复查检查点复查检查点复查和和和和验收检查验收检查验收检查验收检查，可用来，可用来，可用来，可用来保证新软件系统的可保证新软件系统的可保证新软件系统的可保证新软件系统的可维护性维护性维护性维护性。对已有的软件系统，则应当对已有的软件系统，则应当对已有的软件系统，则应当对已有的软件系统，则应当进行周期性的维护检查进行周期性的维护检查进行周期性的维护检查进行周期性的维护检查。软件在运行期间进行修改，会导致软件质量有变坏的软件在运行期间进行修改，会导致软件质量有变坏的软件在运行期间进行修改，会导致软件质量有变坏的软件在运行期间进行修改，会导致软件质量有变坏的危险，破坏程序概念的完整性。危险，破坏程序概念的完整性。危险，破坏程序概念的完整性。危险，破坏程序概念的完整性。必须必须必须必须定期检查定期检查定期检查定期检查，对软件做周期性的维护审查，对软件做周期性的维护审查，对软件做周期性的维护审查，对软件做周期性的维护审查，以跟踪以跟踪以跟踪以跟踪软件质量的变化软件质量的变化软件质量的变化软件质量的变化。周期性维护审查周期性维护审查周期性维护审查周期性维护审查实际上是开发阶段检查点复查的继实际上是开发阶段检查点复查的继实际上是开发阶段检查点复查的继实际上是开发阶段检查点复查的继续，并且采用的检查方法、检查内容都是相同的。续，并且采用的检查方法、检查内容都是相同的。续，并且采用的检查方法、检查内容都是相同的。续，并且采用的检查方法、检查内容都是相同的。维护审查的结果维护审查的结果维护审查的结果维护审查的结果可以同以前的维护审查的结果，以可以同以前的维护审查的结果，以可以同以前的维护审查的结果，以可以同以前的维护审查的结果，以前的验收检查的结果、检查点检查的结果相比较，前的验收检查的结果、检查点检查的结果相比较，前的验收检查的结果、检查点检查的结果相比较，前的验收检查的结果、检查点检查的结果相比较，任何一种改变都表明在软件质量上或其它类型的问任何一种改变都表明在软件质量上或其它类型的问任何一种改变都表明在软件质量上或其它类型的问任何一种改变都表明在软件质量上或其它类型的问题上可能起了变化。题上可能起了变化。题上可能起了变化。题上可能起了变化。对于改变的原因应当进行分析对于改变的原因应当进行分析对于改变的原因应当进行分析对于改变的原因应当进行分析。4.4.对软件包进行检查对软件包进行检查对软件包进行检查对软件包进行检查软件包软件包软件包软件包是一种标准化的，可为不同单位、不同用户使用的软是一种标准化的，可为不同单位、不同用户使用的软是一种标准化的，可为不同单位、不同用户使用的软是一种标准化的，可为不同单位、不同用户使用的软件。件。件。件。一般一般一般一般源代码和程序文档源代码和程序文档源代码和程序文档源代码和程序文档不会提供给用户。不会提供给用户。不会提供给用户。不会提供给用户。对软件包的维护采取以下方法。对软件包的维护采取以下方法。对软件包的维护采取以下方法。对软件包的维护采取以下方法。使用单位的维护人员首先要仔细分析、研究卖主提供的使用单位的维护人员首先要仔细分析、研究卖主提供的使用单位的维护人员首先要仔细分析、研究卖主提供的使用单位的维护人员首先要仔细分析、研究卖主提供的用户手册、操作手册、培训教程等，以及卖方提供的验收用户手册、操作手册、培训教程等，以及卖方提供的验收用户手册、操作手册、培训教程等，以及卖方提供的验收用户手册、操作手册、培训教程等，以及卖方提供的验收测试报告等。测试报告等。测试报告等。测试报告等。在此基础上，深入了解本单位的希望和要求，在此基础上，深入了解本单位的希望和要求，在此基础上，深入了解本单位的希望和要求，在此基础上，深入了解本单位的希望和要求，编制软件包的检验程序。编制软件包的检验程序。编制软件包的检验程序。编制软件包的检验程序。检查软件包程序所执行的功能是否与用户的检查软件包程序所执行的功能是否与用户的检查软件包程序所执行的功能是否与用户的检查软件包程序所执行的功能是否与用户的要求和条件相一致。要求和条件相一致。要求和条件相一致。要求和条件相一致。为了建立这个程序，维护人员可以利用卖方为了建立这个程序，维护人员可以利用卖方为了建立这个程序，维护人员可以利用卖方为了建立这个程序，维护人员可以利用卖方提供的验收测试实例，还可以自己重新设计提供的验收测试实例，还可以自己重新设计提供的验收测试实例，还可以自己重新设计提供的验收测试实例，还可以自己重新设计新的测试实例。新的测试实例。新的测试实例。新的测试实例。根据测试结果，检查和验证软件包的参数或根据测试结果，检查和验证软件包的参数或根据测试结果，检查和验证软件包的参数或根据测试结果，检查和验证软件包的参数或控制结构，以完成软件包的维护。控制结构，以完成软件包的维护。控制结构，以完成软件包的维护。控制结构，以完成软件包的维护。改进程序的文档改进程序的文档程序文档是对程序程序文档是对程序程序文档是对程序程序文档是对程序总目标总目标总目标总目标、程序各组成部分之间的程序各组成部分之间的程序各组成部分之间的程序各组成部分之间的关系关系关系关系、程序设计策略程序设计策略程序设计策略程序设计策略、程序实现过程的历史数据程序实现过程的历史数据程序实现过程的历史数据程序实现过程的历史数据等等等等的说明和补充。的说明和补充。的说明和补充。的说明和补充。即使是一个十分简单的程序，要想有效地、高效率即使是一个十分简单的程序，要想有效地、高效率即使是一个十分简单的程序，要想有效地、高效率即使是一个十分简单的程序，要想有效地、高效率地维护它，也需要编制文档来解释其目的及任务。地维护它，也需要编制文档来解释其目的及任务。地维护它，也需要编制文档来解释其目的及任务。地维护它，也需要编制文档来解释其目的及任务。利用利用利用利用历史文档历史文档历史文档历史文档可以大大简化维护工作可以大大简化维护工作可以大大简化维护工作可以大大简化维护工作：系统开发日志系统开发日志系统开发日志系统开发日志 错误记载错误记载错误记载错误记载 系统维护日志系统维护日志系统维护日志系统维护日志