1、9软件维护的基本概念软件维护的基本概念 软件维护是指软件系统交付使用以后，为了改正错软件维护是指软件系统交付使用以后，为了改正错误或满足新的需求而修改软件的过程。误或满足新的需求而修改软件的过程。软件维护工作处于软件生命期的最后阶段，维护阶软件维护工作处于软件生命期的最后阶段，维护阶段是软件生存期中最长的一个阶段，所花费的人力、物段是软件生存期中最长的一个阶段，所花费的人力、物力最多，其花费高达整个软件生命期花费的约力最多，其花费高达整个软件生命期花费的约60-7060-70。因为计算机程序总是会发生变化，对隐含错误的修改，因为计算机程序总是会发生变化，对隐含错误的修改，新功能的加入，环境变化
2、造成的程序变动等。新功能的加入，环境变化造成的程序变动等。因此，应该充分认识到维护工作的重要性和迫切性，因此，应该充分认识到维护工作的重要性和迫切性，提高软件的可维护性，减少维护的工作量和费用，延长提高软件的可维护性，减少维护的工作量和费用，延长已经开发软件的生命期，以发挥其应有的效益。已经开发软件的生命期，以发挥其应有的效益。9 9.1.1.1.1 软件维护的目的软件维护的目的1.1.在运行中发现在测试阶段未能发现的潜在软件错误和在运行中发现在测试阶段未能发现的潜在软件错误和设计缺陷；设计缺陷；2.2.根据实际情况，需要改进软件设计，以增强软件的功根据实际情况，需要改进软件设计，以增强软件的
3、功能，提高软件的性能；能，提高软件的性能；3.3.要求在某环境下已运行的软件能适应特定的硬件、软要求在某环境下已运行的软件能适应特定的硬件、软件、外部设备和通信设备等新的工作环境，或是要求适件、外部设备和通信设备等新的工作环境，或是要求适应已变动的数据或文件；应已变动的数据或文件；4.4.为使投入运行的软件与其它相关的程序有良好的接口，为使投入运行的软件与其它相关的程序有良好的接口，以利于协同工作；以利于协同工作；5.5.为使运行软件的应用范围得到必要的扩充。为使运行软件的应用范围得到必要的扩充。2022-12-1911软件维护的类型软件维护的类型按照不同的维护目的，维护工作可分成按照不同的维
4、护目的，维护工作可分成4 4类。类。完善性维护完善性维护（Perfective MaintenancePerfective Maintenance）扩充原有系统的功能，提高原有系统的性能，满扩充原有系统的功能，提高原有系统的性能，满足用户的实际需要。足用户的实际需要。纠错性维护纠错性维护（Corrective MaintenanceCorrective Maintenance）对在测试阶段未能发现的，在软件投入使用后才逐对在测试阶段未能发现的，在软件投入使用后才逐渐暴露出来的错误的测试、诊断、定位、纠错以及渐暴露出来的错误的测试、诊断、定位、纠错以及验证、修改的回归测试过程。验证、修改的回归测
5、试过程。适应性维护适应性维护（Adaptive Maintenance）要使运行的软件能适应运行环境的变动而要使运行的软件能适应运行环境的变动而修改软件的过程。修改软件的过程。预防性维护预防性维护（Preventive Maintenance）为了进一步改善软件的可靠性和易维护性，为了进一步改善软件的可靠性和易维护性，或者为将来的维护奠定更好的基础而对软件进或者为将来的维护奠定更好的基础而对软件进行修改。行修改。纠错性维护纠错性维护适应性维护适应性维护完善性维护完善性维护预防性维护预防性维护软件维护的特性软件维护的特性1.1.时间长、工作量大、成本高时间长、工作量大、成本高 软件的维护过程是软
6、件生存期中最长，并且相当困难软件的维护过程是软件生存期中最长，并且相当困难的阶段，软件维护的工作量占整个软件生存期的的阶段，软件维护的工作量占整个软件生存期的70%70%以上，以上，而且还在逐年增加。因此，如何减少软件维护的工作量，而且还在逐年增加。因此，如何减少软件维护的工作量，降低软件维护的成本，就成为提高软件维护效率和质量的降低软件维护的成本，就成为提高软件维护效率和质量的关键。关键。2.2.维护的副作用维护的副作用（1 1）修改代码的副作用。在修改源代码时，由于软件的内）修改代码的副作用。在修改源代码时，由于软件的内在结构等原因，任何一个小的修改都可能引起的错误。因在结构等原因，任何一
7、个小的修改都可能引起的错误。因此在修改时必须特别小心。此在修改时必须特别小心。软件维护的特性软件维护的特性（2 2）修改数据的副作用。在修改数据结构时，有可能造成）修改数据的副作用。在修改数据结构时，有可能造成软件设计与数据结构不匹配，因而导致软件出错。数据软件设计与数据结构不匹配，因而导致软件出错。数据副作用就是修改软件信息结构导致的结果。修改数据副副作用就是修改软件信息结构导致的结果。修改数据副作用可以通过详细的设计文档加以控制，此文档中描述作用可以通过详细的设计文档加以控制，此文档中描述了一种交叉作用，把数据元素、记录、文件和其他结构了一种交叉作用，把数据元素、记录、文件和其他结构联系起
8、来。联系起来。（3 3）修改文档的副作用。对软件的数据流、软件结构、模）修改文档的副作用。对软件的数据流、软件结构、模块逻辑等进行修改时，必须对相关技术文档进行相应修块逻辑等进行修改时，必须对相关技术文档进行相应修改。但修改文档过程会产生新的错误，导致文档与程序改。但修改文档过程会产生新的错误，导致文档与程序功能不匹配，缺省条件改变等错误，产生文档的副作用。功能不匹配，缺省条件改变等错误，产生文档的副作用。为了控制因修改而引起的副作用，应该：按模块把修为了控制因修改而引起的副作用，应该：按模块把修改分组；自顶向下的安排被修改模块的顺序；每次修改改分组；自顶向下的安排被修改模块的顺序；每次修改一
9、个模块。一个模块。3 3、软件维护的困难、软件维护的困难读懂别人的程序困难。读懂别人的程序困难。文档的不一致性。文档的不一致性。软件开发人员和软件维护人员在时间上的差异。软件开发人员和软件维护人员在时间上的差异。软件维护工作是一项难出成果的工作。软件维护工作是一项难出成果的工作。结构化维护结构化维护 指软件开发过程是按照软件工程方法进指软件开发过程是按照软件工程方法进行的，开发各阶段文档齐全，软件的维护过程，有一行的，开发各阶段文档齐全，软件的维护过程，有一整套完整的方案、技术、审定过程。整套完整的方案、技术、审定过程。非结构化维护非结构化维护 只有源程序，缺乏必要的文档说明，只有源程序，缺乏
10、必要的文档说明，难于难于确确定数据结构、系统接口等特性。维护工作令人定数据结构、系统接口等特性。维护工作令人生畏，事倍功半。生畏，事倍功半。软件维护的工作量及模型软件维护的工作量及模型1.1.软件维护的工作量软件维护的工作量 软件维护的费用在整个软件开发费用的软件维护的费用在整个软件开发费用的55%-70%55%-70%，并且所占，并且所占比例在逐年上升。而且维护中还可能产生新的潜在错误。例如比例在逐年上升。而且维护中还可能产生新的潜在错误。例如1970 1970 年维护费用约占软件开发费用的年维护费用约占软件开发费用的40%40%，到，到19901990年维护费用年维护费用所占比例就超过了所
11、占比例就超过了70%70%。另外维护还包含了无形的资源占用，包。另外维护还包含了无形的资源占用，包括大量的使用很多硬件、软件和软件工程师等资源。括大量的使用很多硬件、软件和软件工程师等资源。在软件维护时，直接影响维护成本和工作量的因素很多，在软件维护时，直接影响维护成本和工作量的因素很多，主要如下：主要如下：（1 1）系统规模大小）系统规模大小 系统规模大小直接影响维护工作量，系统规模越大，仅仅系统规模大小直接影响维护工作量，系统规模越大，仅仅看懂理解就很困难，维护的工作量就更多。系统规模主要由源看懂理解就很困难，维护的工作量就更多。系统规模主要由源代码行数、程序模块数、数据接口文件数、使用数
12、据库规模大代码行数、程序模块数、数据接口文件数、使用数据库规模大小等因素衡量。小等因素衡量。软件维护的工作量及模型软件维护的工作量及模型1.1.软件维护的工作量软件维护的工作量（2 2）程序设计语言）程序设计语言 解决相同的问题选择不同的程序设计语言，得到的程序解决相同的问题选择不同的程序设计语言，得到的程序的规模可能不同。的规模可能不同。（3 3）系统使用年限）系统使用年限 使用年限长的老系统维护比新系统所需要的工作量更多。使用年限长的老系统维护比新系统所需要的工作量更多。（4 4）软件开发新技术的应用）软件开发新技术的应用 软件开发过程中，使用先进的分析和设计技术，以及程序软件开发过程中，
13、使用先进的分析和设计技术，以及程序设计技术，如：面向对象的技术、构件技术、可视化程序设设计技术，如：面向对象的技术、构件技术、可视化程序设计技术等，可以减少维护工作量。计技术等，可以减少维护工作量。（5 5）设计过程中的技术）设计过程中的技术 在具体对软件进行维护时，影响维护工作量的其他因素还在具体对软件进行维护时，影响维护工作量的其他因素还有很多，例如设计过程中应用的类型、数学模型、任务的难有很多，例如设计过程中应用的类型、数学模型、任务的难度、开关与标记、度、开关与标记、IF IF 嵌套深度、索引或下标数等。嵌套深度、索引或下标数等。软件维护的工作量及模型软件维护的工作量及模型2.2.软件
14、维护工作量模型软件维护工作量模型 维护活动分为生产性活动和非生产性活动。生产性活动包括分析评维护活动分为生产性活动和非生产性活动。生产性活动包括分析评价、修改设计和编写程序代码等。非生产性活动包括理解程序代码，解价、修改设计和编写程序代码等。非生产性活动包括理解程序代码，解释数据结构，接口特点和设计约束等。释数据结构，接口特点和设计约束等。BeladyBelady 和和Lehman Lehman 提出软件维护工作模型：提出软件维护工作模型：M=P+K M=P+K*EXPEXP（C-DC-D）其中：其中：M维护总工作量维护总工作量P生产性活动生产性活动K经验常数经验常数C程序复杂度（由非结构化维
15、护引起的）程序复杂度（由非结构化维护引起的）D对维护软件熟悉程度的度量。对维护软件熟悉程度的度量。上式可以发现，上式可以发现，C C 越大，越大，D D 越小，那么维护工作量就成指数的增加。越小，那么维护工作量就成指数的增加。C C 增加主要因为软件采用非结构化设计，程序复杂性高；增加主要因为软件采用非结构化设计，程序复杂性高；D D 减小表示维减小表示维护人员不是原来的开发人员，不熟悉程序，理解程序花费太多时间。护人员不是原来的开发人员，不熟悉程序，理解程序花费太多时间。维护费用高达开发费用的维护费用高达开发费用的55%70%，而，而且逐年上涨。且逐年上涨。维护中还可能引入新的潜在错误。维护
16、中还可能引入新的潜在错误。Belady 和和 Lehman 提出软件维护工作模型：提出软件维护工作模型：M=P+K*EXP（C-D）其中：其中：M维护总工作量维护总工作量P生产性活动生产性活动K经验常数经验常数C程序复杂度（由非结构化维护引起的）程序复杂度（由非结构化维护引起的）D对维护软件熟悉程度的度量。对维护软件熟悉程度的度量。结论结论软件维护的过程软件维护的过程1.1.维护组织维护组织 除大的软件公司外，通常的在软件维护工作方面，并不除大的软件公司外，通常的在软件维护工作方面，并不保持一个正式的组织。在软件开发部门，确立一个非正式的保持一个正式的组织。在软件开发部门，确立一个非正式的维护
17、组织即非正式的维护管理员来负责维护工作却是绝对必维护组织即非正式的维护管理员来负责维护工作却是绝对必要的。要的。用户用户维护人员维护人员安排改正安排改正性维护性维护确认维确认维护类型护类型维护实施维护实施评价优评价优先级先级进行问进行问题分析题分析复审复审评价错误评价错误严重程度严重程度进行问进行问题分析题分析确定更确定更改要求改要求维护维护要求要求完完 美美 性性 适适 应应 性性将安排好的工将安排好的工作量列入计划作量列入计划低低高高纠错性纠错性严重严重不严重不严重将改正错误列入计划将改正错误列入计划 人人 员员 安安排排人人 员员 安安 排排交付使用交付使用的软件的软件理解分析程序理解分
18、析程序安排计划安排计划修改程序修改程序测试程序测试程序或或或或或或或或软件维护的工作流程图软件维护的工作流程图修改过修改过的软件的软件 软件维护工作不仅是技术性的，它还需要大量的管软件维护工作不仅是技术性的，它还需要大量的管理工作与之相配合，才能保证维护工作的质量。管理部理工作与之相配合，才能保证维护工作的质量。管理部门应对提交的修改方案进行分析和审查，并对修改带来门应对提交的修改方案进行分析和审查，并对修改带来的影响作充分的估计，对于不妥的修改予以撤销。需修的影响作充分的估计，对于不妥的修改予以撤销。需修改主文档时，管理部门更应仔细审查。改主文档时，管理部门更应仔细审查。软件维护的管理流程如
19、图所示：软件维护的管理流程如图所示：软件维护的管理流程软件维护的管理流程 维护修改建议维护修改建议 分析修改建议分析修改建议是否合理是否合理提交管理部门审查提交管理部门审查是否同意是否同意修改修改撤销撤销NYNY进行测试进行测试 提交管理部门审批提交管理部门审批是否批准是否批准更新主文档更新主文档Y 更新其他文档更新其他文档 提交使用提交使用修改修改N一、结构化维护与非结构化维护一、结构化维护与非结构化维护结构化维护结构化维护 指软件开发过程是按照软件工指软件开发过程是按照软件工程方法，软件的维护过程，有一整套完整的方案、程方法，软件的维护过程，有一整套完整的方案、技术、审定过程。技术、审定过
20、程。非结构化维护非结构化维护 缺乏必要的文档说明，难于缺乏必要的文档说明，难于确确定数据结构、系统接口等特性。维护工作令人定数据结构、系统接口等特性。维护工作令人生畏，事倍功半。生畏，事倍功半。维护费用高达开发费用的维护费用高达开发费用的55%70%，而，而且逐年上涨。且逐年上涨。维护中还可能引入新的潜在错误。维护中还可能引入新的潜在错误。Belady 和和 Lehman 提出软件维护工作模型：提出软件维护工作模型：M=P+K*EXP（C-D）其中：其中：M维护总工作量维护总工作量P生产性活动生产性活动K经验常数经验常数C程序复杂度（由非结构化维护引起的）程序复杂度（由非结构化维护引起的）D对
21、维护软件熟悉程度的度量。对维护软件熟悉程度的度量。结论结论软件维护的技术软件维护的技术在软件开发阶段用来减少错误，提高软件可在软件开发阶段用来减少错误，提高软件可维护性的技术。涉及到软件开发的所有阶段。维护性的技术。涉及到软件开发的所有阶段。可维护性可维护性（可测试性、可理解性、可修改性）（可测试性、可理解性、可修改性）在软件维护阶段用于提高维护工作的效率和在软件维护阶段用于提高维护工作的效率和质量的技术。主要用到质量的技术。主要用到测试测试阶段的技术。阶段的技术。（信息收集、错误原因分析、软件分析与理解、（信息收集、错误原因分析、软件分析与理解、维护方案评价、代码与文档的修改、修改后的确维护
22、方案评价、代码与文档的修改、修改后的确认。）认。）维护支援技术是在软件维护阶段用来提高维护作业的效率和质维护支援技术是在软件维护阶段用来提高维护作业的效率和质量的技术。包括：量的技术。包括：1.信息收集：收集有关系统在运行过程中的各种问题。信息收集：收集有关系统在运行过程中的各种问题。2.错误原因分析：分析所收集到的信息，分析出错的原因。错误原因分析：分析所收集到的信息，分析出错的原因。3.软件分析与理解：只有对需要维护的软件进行认真的理解，软件分析与理解：只有对需要维护的软件进行认真的理解，才保证软件维护正确进行。才保证软件维护正确进行。4.维护方案评价：在进行维护修改前，要确定维护方案，并
23、由维护方案评价：在进行维护修改前，要确定维护方案，并由相关的组织进行评审通过后才能执行。相关的组织进行评审通过后才能执行。5.代码与文档修改：实施维护方案。代码与文档修改：实施维护方案。6.修改后的确认：经过修改的软件，需要重新进行测试。修改后的确认：经过修改的软件，需要重新进行测试。7.远距离的维护：对于网络系统，可以通过远程控制进行维护。远距离的维护：对于网络系统，可以通过远程控制进行维护。为了更好地做好软件维护工作，包括估计维护的有效为了更好地做好软件维护工作，包括估计维护的有效程度，确定软件产品的质量，确定维护的实际开销等，应程度，确定软件产品的质量，确定维护的实际开销等，应该在维护的
24、过程中记录好维护全过程，建立维护档案。该在维护的过程中记录好维护全过程，建立维护档案。对于维护工作地评价一般较为困难，因为很多时候没对于维护工作地评价一般较为困难，因为很多时候没有量化的数据，但可记录维护性能地度量值，这些度量值有量化的数据，但可记录维护性能地度量值，这些度量值一般有：一般有：l记录维护申请报告的平均处理时间；记录维护申请报告的平均处理时间；l统计每类维护上的总统计每类维护上的总“人时人时”数的开销；数的开销；l统计每次程序运行时的平均出错次数；统计每次程序运行时的平均出错次数；l统计在维护中，增删每个源程序语句所花费的平均统计在维护中，增删每个源程序语句所花费的平均“人人时时
25、”数；数；l记录每段程序、每种语言、每种维护类型的程序平均修记录每段程序、每种语言、每种维护类型的程序平均修改次数；改次数；l统计所用语言及用于每种语言的平均统计所用语言及用于每种语言的平均“人时人时”数计算各数计算各类维护申请的百分比；类维护申请的百分比；l这些度量值提供的是定量数据，可以评价维护工作。这些度量值提供的是定量数据，可以评价维护工作。9.4 软件可维护性软件可维护性 许多软件的维护很困难，主要因为软件的源程序和文档难于许多软件的维护很困难，主要因为软件的源程序和文档难于理解和修改。由于维护工作面广，维护的难度大，稍有不慎，就理解和修改。由于维护工作面广，维护的难度大，稍有不慎，
26、就会在修改中给软件带来新的问题或引入新的错误，所以为了使得会在修改中给软件带来新的问题或引入新的错误，所以为了使得软件能够易于维护，必须考虑使软件具有可维护性。软件能够易于维护，必须考虑使软件具有可维护性。9.4.1 软件可维护性的定义软件可维护性的定义 软件可维护性是指软件能够被理解，并能纠正软件系统出现软件可维护性是指软件能够被理解，并能纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。软件的可维护性、可使用性和可靠性是衡量软件质量的易程度。软件的可维护性、可使用性和可靠性是衡量软件质量的几个主要特性，也
27、是用户最关心的问题之一。但影响软件质量的几个主要特性，也是用户最关心的问题之一。但影响软件质量的这些因素，目前还没有普遍适用的定量度量的方法。这些因素，目前还没有普遍适用的定量度量的方法。软件维护可用如下的七个质量特性来衡量，即可软件维护可用如下的七个质量特性来衡量，即可理解性、可测试性、可修改性、可靠性、可移植性、理解性、可测试性、可修改性、可靠性、可移植性、可使用性和效率。而且对于不同类型的维护，这七种可使用性和效率。而且对于不同类型的维护，这七种特性的侧重点也不相同。特性的侧重点也不相同。目前广泛使用的衡量程序的可维护性的七种特性如表目前广泛使用的衡量程序的可维护性的七种特性如表所示。所
28、示。9.4.2 可维护性的度量可维护性的度量 由于许多质量特性是相互抵触的，要考虑几种不同由于许多质量特性是相互抵触的，要考虑几种不同的度量标准，去度量不同的质量特性。的度量标准，去度量不同的质量特性。1.可理解性可理解性 一个可理解的软件主要应该具备的特性是：模块化，一个可理解的软件主要应该具备的特性是：模块化，风格一致性，使用清晰明确的代码，使用有意义的数据风格一致性，使用清晰明确的代码，使用有意义的数据名和过程名，结构化，完整性等。名和过程名，结构化，完整性等。对于可理解性，对于可理解性，Shneiderman 提出一种叫做提出一种叫做“90-10 测测试法试法”来衡量。即让有经验的程序
29、员阅读来衡量。即让有经验的程序员阅读10 分钟要测试分钟要测试的程序，然后如能凭记忆和理解写出的程序，然后如能凭记忆和理解写出90的程序，则称的程序，则称该程序是可理解的。该程序是可理解的。2.可靠性可靠性 可靠性表明一个软件按照用户的要求和设计目标，可靠性表明一个软件按照用户的要求和设计目标，在给定的一段时间内正确执行的概率。可靠性的主要在给定的一段时间内正确执行的概率。可靠性的主要度量标准有：平均失效间隔时间、平均修复时间、有度量标准有：平均失效间隔时间、平均修复时间、有效性。度量可靠性的方法，主要有两类：效性。度量可靠性的方法，主要有两类：（1）根据软件错误统计数字，进行可靠性预测。）根
30、据软件错误统计数字，进行可靠性预测。（2）根据软件复杂性，预测软件可靠性。）根据软件复杂性，预测软件可靠性。3.可测试性可测试性 可测试性表明论证软件正确性的容易程度。对于可测试性表明论证软件正确性的容易程度。对于软件中的程序模块，可用程序复杂性来度量可测试性。软件中的程序模块，可用程序复杂性来度量可测试性。明显地，程序的环路复杂性越大，程序的路径就越多，明显地，程序的环路复杂性越大，程序的路径就越多，全面测试程序的难度就越大。全面测试程序的难度就越大。4.可修改性可修改性 测试可修改性的一种定量方法是修改练习。基本思想是通过测试可修改性的一种定量方法是修改练习。基本思想是通过做几个简单的修改
31、，来评价修改难度。设做几个简单的修改，来评价修改难度。设C 是程序中各个模块的是程序中各个模块的平均复杂性，平均复杂性，n 是必须修改的模块数，是必须修改的模块数，A 是要修改的模块的平均是要修改的模块的平均复杂性。则修改的难度表示为：复杂性。则修改的难度表示为：D=A/C在简单修改时当在简单修改时当D1，说明该软件修改困难。，说明该软件修改困难。A 和和C 可用任何一可用任何一种度量程序复杂性的方法计算。种度量程序复杂性的方法计算。5.可移植性可移植性 表明软件转移到一个新的计算环境的可能性的大小。或者软表明软件转移到一个新的计算环境的可能性的大小。或者软件能有效地在各种环境中运行的容易程度
32、。一个可移植性好的软件能有效地在各种环境中运行的容易程度。一个可移植性好的软件应具有良好、灵活、不依赖于某一具体计算机或操作系统的性件应具有良好、灵活、不依赖于某一具体计算机或操作系统的性能。能。6.效率效率 效率表明一个软件能执行预定功能而又不浪费机器资源的程效率表明一个软件能执行预定功能而又不浪费机器资源的程度。包括：内存容量、外存容量、通道容量和执行时间。度。包括：内存容量、外存容量、通道容量和执行时间。7.可使用性可使用性 从用户的角度出发，可使用性是软件方便、实用、及易于使从用户的角度出发，可使用性是软件方便、实用、及易于使用的程度。一个可使用的程序应该易于使用、允许出错和修改，用的
33、程度。一个可使用的程序应该易于使用、允许出错和修改，而且尽量保证用户在使用时不陷入混乱状态。而且尽量保证用户在使用时不陷入混乱状态。9.4.3 提高可维护性的方法提高可维护性的方法 软件的可维护性对于延长软件的生存期具有决定意义，软件的可维护性对于延长软件的生存期具有决定意义，因此必须考虑怎样才能提高软件的可维护性。为此，可从因此必须考虑怎样才能提高软件的可维护性。为此，可从以下五个方面着手。以下五个方面着手。1.建立明确的软件质量目标建立明确的软件质量目标2.使用先进的软件开发技术和工具使用先进的软件开发技术和工具 利用先进的软件开发技术是软件开发过程中提高软件利用先进的软件开发技术是软件开
34、发过程中提高软件质量，降低成本的有效方法之一，也是提高可维护性的有质量，降低成本的有效方法之一，也是提高可维护性的有效的技术。常用的技术有：模块化、结构化程序设计，自效的技术。常用的技术有：模块化、结构化程序设计，自动重建结构和重新格式化的工具等。例如，面向对象的软动重建结构和重新格式化的工具等。例如，面向对象的软件开发方法就是一个非常使用而强有力的软件开发方法。件开发方法就是一个非常使用而强有力的软件开发方法。3.建立明确的质量保证工作建立明确的质量保证工作 质量保证是提高软件质量所做的各种检查工作。在软质量保证是提高软件质量所做的各种检查工作。在软件开发和软件维护的各阶段，质量保证检查是非
35、常有效的件开发和软件维护的各阶段，质量保证检查是非常有效的方法。为了保证软件的可维护性，有四种类型的软件检查：方法。为了保证软件的可维护性，有四种类型的软件检查：（1）在检查点进行复审）在检查点进行复审4.选择可维护的程序设计语言5.改进程序的文档（1）程序文档）程序文档（2）用户文档）用户文档（3）操作文档）操作文档（4）数据文档）数据文档（5）历史文档）历史文档 需要对旧的软件进行重新处理、调整，提高其可维护性，需要对旧的软件进行重新处理、调整，提高其可维护性，这种活动称为这种活动称为“软件再工程软件再工程”，是提高软件可维护性的一类，是提高软件可维护性的一类重要的软件工程活动重要的软件工
36、程活动 。再工程也称复壮（修理）或再生。它不仅能从已存在的再工程也称复壮（修理）或再生。它不仅能从已存在的程序中重新获得设计信息，而且还能使用这些信息来改建或程序中重新获得设计信息，而且还能使用这些信息来改建或重构现有的系统，以改善它的综合质量。一般软件人员利用重构现有的系统，以改善它的综合质量。一般软件人员利用再工程重新实现已存在的程序，同时加进新的功能或改善它再工程重新实现已存在的程序，同时加进新的功能或改善它的性能。的性能。软件的逆向工程是分析程序，力图在比源代码更高抽象软件的逆向工程是分析程序，力图在比源代码更高抽象层次上建立程序表示的过程；是一个设计恢复的过程。使用层次上建立程序表示
37、的过程；是一个设计恢复的过程。使用逆向工程工具可以从已经存在的软件中提取数据结构、体系逆向工程工具可以从已经存在的软件中提取数据结构、体系结构和程序设计结构。逆向工程的过程如图所示。结构和程序设计结构。逆向工程的过程如图所示。逆向工程的过程从源代码重构开始，将无结构的源代逆向工程的过程从源代码重构开始，将无结构的源代码转换为结构化的源代码，提高了源代码的易读性。抽取码转换为结构化的源代码，提高了源代码的易读性。抽取是逆向工程的核心，内容包括处理抽取、界面抽取和数据是逆向工程的核心，内容包括处理抽取、界面抽取和数据抽取。抽取。处理抽取可在不同层次进行；如语句段、模块、子系处理抽取可在不同层次进行
38、；如语句段、模块、子系统、系统。使用逆向工程工具，可以从已存在程序中抽取统、系统。使用逆向工程工具，可以从已存在程序中抽取数据结构、体系结构和程序设计信息。数据结构、体系结构和程序设计信息。软件重构是对源代码、数据进行修改，使其易于修改和软件重构是对源代码、数据进行修改，使其易于修改和维护，以适应将来的变更。通常软件重构并不修改软件体系维护，以适应将来的变更。通常软件重构并不修改软件体系结构，而是关注模块的细节。结构，而是关注模块的细节。1 1、代码重构、代码重构 代码重构的目标是生成可提供功能相同，而质量更高的代码重构的目标是生成可提供功能相同，而质量更高的程序。程序。2 2、数据重构、数据
39、重构 发生在较低的抽象层次上，是一种全局的再工程活动。发生在较低的抽象层次上，是一种全局的再工程活动。数据重构通常以逆向工程活动开始，理解现存的数据结构，数据重构通常以逆向工程活动开始，理解现存的数据结构，又称数据分析，再重新设计数据，包括数据标准化、数据命又称数据分析，再重新设计数据，包括数据标准化、数据命名合理、文件格式转换、数据库格式转换等。名合理、文件格式转换、数据库格式转换等。3 3、软件重构的意义、软件重构的意义 提高软件质量和生产率，减少维护工作量，提高软件可提高软件质量和生产率，减少维护工作量，提高软件可维护性。维护性。再工程要耗费时间，占用资源。为了降低再工程的风险，再工程要
40、耗费时间，占用资源。为了降低再工程的风险，必须进行成本效益分析。必须进行成本效益分析。Sneed Sneed 提出了再工程的成本效益提出了再工程的成本效益模型：模型：1.1.与未执行再工程的持续维护相关的成本：与未执行再工程的持续维护相关的成本：2.2.与再工程相关的成本：与再工程相关的成本：3.3.再工程的整体收益：再工程的整体收益：其中：其中：p1 p1：当前某应用的年维护成本；：当前某应用的年维护成本；p2 p2：当前某应用的年运行成本；：当前某应用的年运行成本；p3 p3：当前某应用的年收益；：当前某应用的年收益；p4 p4：再工程后预期年维护成本；：再工程后预期年维护成本；p5 p5
41、：再工程后预期年运行成本；：再工程后预期年运行成本；p6 p6：再工程后预期业务收益；：再工程后预期业务收益；p7 p7：估计的再工程成本；：估计的再工程成本；p8 p8：估计的再工程日程；：估计的再工程日程；p9 p9：再工程的风险因子（：再工程的风险因子（=1.0=1.0）L L：期望的系统生命期（年）：期望的系统生命期（年）再工程的风险主要有以下几个方面：再工程的风险主要有以下几个方面：.过程风险：在进行再工程活动中，缺乏对投入人过程风险：在进行再工程活动中，缺乏对投入人员的管理；员的管理；及对再工程方案的实施缺乏管理，未作成本及对再工程方案的实施缺乏管理，未作成本效益分析。效益分析。.
42、应用领域风险：对再工程项目中的业务知识不熟应用领域风险：对再工程项目中的业务知识不熟悉，缺少专业悉，缺少专业 领域的专家支持。领域的专家支持。.技术风险：缺乏再工程技术支持，恢复设计得到的信技术风险：缺乏再工程技术支持，恢复设计得到的信息无用等。息无用等。4.4.人员风险，工具风险等。人员风险，工具风险等。软件再工程是提高软件可维护性的一类重要的软件工软件再工程是提高软件可维护性的一类重要的软件工程活动。与软件开发相比，软件再工程不是从编写规格说程活动。与软件开发相比，软件再工程不是从编写规格说明开始，而是从原有的软件出发，通过再工程，获得可维明开始，而是从原有的软件出发，通过再工程，获得可维护性好的新软件。护性好的新软件。
