第8章软件维护

1、第8章 软件维护 8.1 软件维护的内容 8.2 软件维护的特点 8.3 软件维护过程 8.4 软件的可维护性 8.5 软件再工程过程 实例分析 本章小结软件开发完成交付用户使用后，就进入生存周期软件开发完成交付用户使用后，就进入生存周期的最后一个阶段的最后一个阶段软件的运行和维护阶段。软件软件的运行和维护阶段。软件维护工作处于软件生命期的最后阶段，维护阶段也维护工作处于软件生命期的最后阶段，维护阶段也是软件生存期中最长的一个阶段，所花费的人力、是软件生存期中最长的一个阶段，所花费的人力、物力最多，其花费高达整个软件生命期花费的约物力最多，其花费高达整个软件生命期花费的约6070。因为计算机程

2、序总是会发生变化，对隐。因为计算机程序总是会发生变化，对隐含错误的修改，新功能的加入，环境变化造成的程含错误的修改，新功能的加入，环境变化造成的程序变动等。因此，做好维护工作具有特别重要的意序变动等。因此，做好维护工作具有特别重要的意义，应该充分认识到维护工作的重要性和迫切性，义，应该充分认识到维护工作的重要性和迫切性，提高软件的可维护性，减少维护的工作量和费用，提高软件的可维护性，减少维护的工作量和费用，延长已经开发软件的生命期，以发挥其应有的效益。延长已经开发软件的生命期，以发挥其应有的效益。 8.1 软件维护的内容8.1.1 8.1.1 软件维护的定义软件维护的定义软件维护是指软件系统交

3、付使用以后，为了改正软件维护是指软件系统交付使用以后，为了改正软件运行错误，或者因满足新的需求而加入新功能的软件运行错误，或者因满足新的需求而加入新功能的修改软件的过程。修改软件的过程。软件维护是软件工程的一个重要任务，其主要工软件维护是软件工程的一个重要任务，其主要工作就是在软件运行和维护阶段对软件产品所进行必要作就是在软件运行和维护阶段对软件产品所进行必要的调整和修改。要求进行维护的原因主要分为如下几的调整和修改。要求进行维护的原因主要分为如下几种：种：8.1 软件维护的内容1. 在运行中发现在测试阶段未能发现的潜在软在运行中发现在测试阶段未能发现的潜在软件错误和设计缺陷，而这些错误或缺陷

4、在特定的使用件错误和设计缺陷，而这些错误或缺陷在特定的使用条件下暴露出来了。条件下暴露出来了。2. 用户和数据处理人员在使用时常提出改进现用户和数据处理人员在使用时常提出改进现有功能，增加新的功能，以及改善总体性能的要求，有功能，增加新的功能，以及改善总体性能的要求，为满足这些要求，就需要修改软件把这些要求纳入到为满足这些要求，就需要修改软件把这些要求纳入到软件之中。软件之中。3. 因在软件使用过程中数据环境发生变化（例因在软件使用过程中数据环境发生变化（例如一个事务处理代码发生改变）或处理环境发生变化如一个事务处理代码发生改变）或处理环境发生变化（例如安装了新的硬件或操作系统），需要修改软件

5、（例如安装了新的硬件或操作系统），需要修改软件以适应这种变化。以适应这种变化。8.1 软件维护的内容4. 为使投入运行的软件与其它相关的程序有良为使投入运行的软件与其它相关的程序有良好的接口，以利于协同工作；好的接口，以利于协同工作；5. 为使运行软件的应用范围得到必要的扩充。为使运行软件的应用范围得到必要的扩充。随着社会对计算机的需求越来越大，要求软件必须快随着社会对计算机的需求越来越大，要求软件必须快速发展。在软件快速发展的同时，应该考虑软件的开速发展。在软件快速发展的同时，应该考虑软件的开发成本，显然，对软件进行维护的目的是为了纠正软发成本，显然，对软件进行维护的目的是为了纠正软件开发过

6、程未发现的错误，增强、改进和完善软件的件开发过程未发现的错误，增强、改进和完善软件的功能和性能，以适应软件的发展，延长软件的寿命让功能和性能，以适应软件的发展，延长软件的寿命让其创造更多的价值。其创造更多的价值。8.1 软件维护的内容8.2.2 8.2.2 软件维护的类型及策略软件维护的类型及策略软件的维护并不只是修正错误。按维护性质不同，软件的维护并不只是修正错误。按维护性质不同，软件维护可分为：校正性维护、适应性维护、完善性软件维护可分为：校正性维护、适应性维护、完善性维护和预防性维护。维护和预防性维护。8.1 软件维护的内容1. 完善性维护完善性维护在软件漫长的使用过程中，用户在使用过程

7、中往往会对在软件漫长的使用过程中，用户在使用过程中往往会对软件提出的新的功能与性能要求。这是因为用户的业务会发软件提出的新的功能与性能要求。这是因为用户的业务会发生变化，组织机构也会发生变化，为适应这些变化，需要对生变化，组织机构也会发生变化，为适应这些变化，需要对原来的软件的功能进行修改或扩充。这种扩充软件功能、增原来的软件的功能进行修改或扩充。这种扩充软件功能、增强软件性能、提高软件运行效率和可维护性而进行的维护活强软件性能、提高软件运行效率和可维护性而进行的维护活动称为完善性维护。此维护活动工作量较大占整个维护工作动称为完善性维护。此维护活动工作量较大占整个维护工作的的50%。例如：对人

8、事管理程序，在使用中要不断修改人事。例如：对人事管理程序，在使用中要不断修改人事管理程序，使其增加或删除新的项目，满足新需求；原来软管理程序，使其增加或删除新的项目，满足新需求；原来软件的查询响应速度较慢，要提高软件的响应速度；改变原来件的查询响应速度较慢，要提高软件的响应速度；改变原来软件的用户界面或增加联机帮助信息；为软件的运行增加监软件的用户界面或增加联机帮助信息；为软件的运行增加监控设施等。控设施等。此项维护主要采用的策略可以使用功能强、使用方便的此项维护主要采用的策略可以使用功能强、使用方便的工具，采用原型化方法开发等。工具，采用原型化方法开发等。8.1 软件维护的内容2. 适应性维

9、护适应性维护随着计算机技术的飞速发展，计算机软硬件环境不断发随着计算机技术的飞速发展，计算机软硬件环境不断发生变化，数据环境也在不断变化。适应性维护是为了使软件生变化，数据环境也在不断变化。适应性维护是为了使软件适应外部新的硬件和软件环境或者数据环境（数据库、数据适应外部新的硬件和软件环境或者数据环境（数据库、数据格式、数据输入格式、数据输入/输出方式、数据存储介质）发生的变化，而输出方式、数据存储介质）发生的变化，而进行修改软件的过程。适应性维护占整个维护工作的进行修改软件的过程。适应性维护占整个维护工作的25%。例如：为现有的某个应用问题实现一个数据库管理系统；对例如：为现有的某个应用问题

10、实现一个数据库管理系统；对某个指定代码进行修改，如：从某个指定代码进行修改，如：从3个字符改为个字符改为4个字符；缩短个字符；缩短系统的应答时间，使其达到特定的要求。系统的应答时间，使其达到特定的要求。它主要的维护策略是对可能变化的因素进行配置管理，它主要的维护策略是对可能变化的因素进行配置管理，将因环境变化而必须修改的部分局部化，即局限于某些程序将因环境变化而必须修改的部分局部化，即局限于某些程序模块等。模块等。8.1 软件维护的内容3. 校正性维护校正性维护软件测试不可能找出一个软件系统中所有潜伏的错误，软件测试不可能找出一个软件系统中所有潜伏的错误，在软件交付使用后，软件在特定情况下运行

11、时，这些潜伏的在软件交付使用后，软件在特定情况下运行时，这些潜伏的错误可能会暴露出来。为了识别和纠正这些错误，修改软件错误可能会暴露出来。为了识别和纠正这些错误，修改软件性能上的缺陷，而进行确定和修改错误的过程，称为校正性性能上的缺陷，而进行确定和修改错误的过程，称为校正性维护。纠错性维护占整个维护工作的维护。纠错性维护占整个维护工作的21%，例如：修正原来，例如：修正原来程序中并未使开关复原的错误；解决开发时未能测试各种可程序中并未使开关复原的错误；解决开发时未能测试各种可能条件带来的问题；解决原来程序中遗漏处理文件中最后一能条件带来的问题；解决原来程序中遗漏处理文件中最后一个记录的问题。个

12、记录的问题。它的主要维护策略是开发过程中采用新技术，利用应用它的主要维护策略是开发过程中采用新技术，利用应用软件包，提高系统结构化程度，进行周期性维护审查等。软件包，提高系统结构化程度，进行周期性维护审查等。8.2 软件维护的特点1. 软件维护时间长、工作量大、成本高软件维护时间长、工作量大、成本高软件的维护过程是软件生存期中最长，并且相当困难的软件的维护过程是软件生存期中最长，并且相当困难的阶段，软件维护的工作量占整个软件生存期的以上，阶段，软件维护的工作量占整个软件生存期的以上，软件维护的费用占整个软件开发预算的百分比正在增加。因软件维护的费用占整个软件开发预算的百分比正在增加。因此，如何

13、减少软件维护的工作量，降低软件维护的成本，就此，如何减少软件维护的工作量，降低软件维护的成本，就成为提高软件维护效率和质量的关键。成为提高软件维护效率和质量的关键。2. 软件维护副作用软件维护副作用维护的目的是为了延长软件的寿命并让其创造更多的价维护的目的是为了延长软件的寿命并让其创造更多的价值，经过在段时间的维护，软件中的错误减少了，功能增强值，经过在段时间的维护，软件中的错误减少了，功能增强了。但是，修改软件是危险的，每修改一次，可能会产生新了。但是，修改软件是危险的，每修改一次，可能会产生新的潜在错误。因此，维护的副作用是指由于修改软件而造成的潜在错误。因此，维护的副作用是指由于修改软件

14、而造成新的错误或其他不希望出现的情况。一般维护产生的副作用新的错误或其他不希望出现的情况。一般维护产生的副作用有如下三种。有如下三种。8.2 软件维护的特点(1) 代码副作用：在使用程序设计语言修改源代码时可代码副作用：在使用程序设计语言修改源代码时可能引入如下错误：能引入如下错误： 修改或删除子程序；修改或删除子程序；修改或删除语句标号；修改或删除语句标号；修改或删除标识符；修改或删除标识符；为提高执行效率而做的修改；为提高执行效率而做的修改；修改文件的打开或关闭操作；修改文件的打开或关闭操作；修改逻辑操作符；修改逻辑操作符；由设计变动引起的代码修改；由设计变动引起的代码修改；修改对边界条件

15、的测试。修改对边界条件的测试。代码副作用有时通过回归测试即可发现，此时应立即采代码副作用有时通过回归测试即可发现，此时应立即采取补救措施；然而，有时直到交付运行后才暴露出来，故对取补救措施；然而，有时直到交付运行后才暴露出来，故对代码进行上述修改应特别慎重。代码进行上述修改应特别慎重。8.2 软件维护的特点(2) 数据副作用：在修改数据结构时，有可能造成软件数据副作用：在修改数据结构时，有可能造成软件设计与数据结构不匹配，因而导致软件出错。容易引起数据设计与数据结构不匹配，因而导致软件出错。容易引起数据副作用的修改包括：副作用的修改包括：局部或全局常量的再定义；局部或全局常量的再定义；记录或文

16、件格式的再定义；记录或文件格式的再定义；增减一个数组或高层数据结构的大小；增减一个数组或高层数据结构的大小；修改全局数据；修改全局数据；重新初始化控制标志和指针；重新初始化控制标志和指针；重新排列输入重新排列输入/输出表或子程序参数表。输出表或子程序参数表。以上这些情况都容易导致设计与数据不相容的错误。设以上这些情况都容易导致设计与数据不相容的错误。设计文档化有助于限制数据副作用，因为设计文档中详细地描计文档化有助于限制数据副作用，因为设计文档中详细地描述了数据结构并提供一个交叉访问表，把数据及引用它们的述了数据结构并提供一个交叉访问表，把数据及引用它们的模块一一对应起来。模块一一对应起来。8

17、.2 软件维护的特点(3) 文档副作用：对软件的数据流、软件结构、模文档副作用：对软件的数据流、软件结构、模块逻辑等进行修改时，必须对相关技术文档进行相应修块逻辑等进行修改时，必须对相关技术文档进行相应修改。否则会导致文档与程序功能不匹配、缺省条件改变改。否则会导致文档与程序功能不匹配、缺省条件改变等错误，产生文档的副作用。如果对可执行软件的修改等错误，产生文档的副作用。如果对可执行软件的修改没有反映在文档中，会产生如下文档副作用：没有反映在文档中，会产生如下文档副作用：修改交互输入的顺序和格式，没有正确的记入文档修改交互输入的顺序和格式，没有正确的记入文档中；中；过时的文档内容、索引和文本可

18、能造成冲突等。过时的文档内容、索引和文本可能造成冲突等。为了控制因修改而引起的副作用，应该：按模块把为了控制因修改而引起的副作用，应该：按模块把修改分组；自顶向下的安排被修改模块的顺序；每次修修改分组；自顶向下的安排被修改模块的顺序；每次修改一个模块。改一个模块。8.2 软件维护的特点3. 软件维护的困难性软件维护的困难性由于软件维护工作通常并不由软件的设计和开发人员来由于软件维护工作通常并不由软件的设计和开发人员来完成，维护人员首先要对软件各阶段的文档和代码进行分析、完成，维护人员首先要对软件各阶段的文档和代码进行分析、理解。因而出现了理解别人的程序困难、文档不齐等问题，理解。因而出现了理解

19、别人的程序困难、文档不齐等问题，尤其是对大型、复杂系统的维护，更加困难和复杂。尤其是对大型、复杂系统的维护，更加困难和复杂。(1) 结构化维护和非结构化维护结构化维护和非结构化维护 非结构化维护是只有源程序，缺乏必要的文档说明，非结构化维护是只有源程序，缺乏必要的文档说明，难于确定数据结构、系统接口等特性。特别是由于没有保存难于确定数据结构、系统接口等特性。特别是由于没有保存测试记录，使回归测试无法进行。所以，改变程序代码所引测试记录，使回归测试无法进行。所以，改变程序代码所引起的后果将难以确定。现在，对于一些非结构化程序的维护起的后果将难以确定。现在，对于一些非结构化程序的维护工作就是这样，

20、不仅浪费了人力物力，还使维护人员的积极工作就是这样，不仅浪费了人力物力，还使维护人员的积极性受到打击。这种情况就是不使用软件工程方法开发软件的性受到打击。这种情况就是不使用软件工程方法开发软件的必然结果。必然结果。8.2 软件维护的特点 结构化维护是指软件开发过程是按照软件工程方结构化维护是指软件开发过程是按照软件工程方法进行，开发各阶段文档齐全，软件的维护过程，有一法进行，开发各阶段文档齐全，软件的维护过程，有一整套完整的方案、技术、审定过程。这对于减少精力、整套完整的方案、技术、审定过程。这对于减少精力、减少花费和提高软件维护效率有很大的作用。减少花费和提高软件维护效率有很大的作用。可以看

21、到，维护工作的难度及工作量的大小，明显可以看到，维护工作的难度及工作量的大小，明显的与前期的开发工作密切相关。的与前期的开发工作密切相关。8.2 软件维护的特点(2) 维护的困难维护的困难软件维护的困难主要是由于软件需求分析和开发方法软件维护的困难主要是由于软件需求分析和开发方法的缺陷造成的。这种困难主要有如下几个方面：的缺陷造成的。这种困难主要有如下几个方面： 读懂别人编的程序是困难的。要修改别人的程序，读懂别人编的程序是困难的。要修改别人的程序，首先要读懂和理解别人的程序。而理解别人的程序是非常首先要读懂和理解别人的程序。而理解别人的程序是非常困难的，如果没有相应的文档，困难就达到非常严重

22、的地困难的，如果没有相应的文档，困难就达到非常严重的地步。步。 文档的不一致性。文档不一致会导致维护人员不文档的不一致性。文档不一致会导致维护人员不知所措，不知根据什么进行修改。这种不一致是由于开发知所措，不知根据什么进行修改。这种不一致是由于开发过程中文档管理不严造成的，在开发中经常出现修改程序过程中文档管理不严造成的，在开发中经常出现修改程序却遗忘了修改与其相关的文档，或某一文档进行了修改，却遗忘了修改与其相关的文档，或某一文档进行了修改，却没有修改与其相关的另一文档。却没有修改与其相关的另一文档。8.2 软件维护的特点 软件开发和软件维护在人员和时间上的差异。通软件开发和软件维护在人员和

23、时间上的差异。通常开发人员与维护人员是不同的，这种差异会导致维护常开发人员与维护人员是不同的，这种差异会导致维护的困难。另外由于维护阶段持续时间很长，正在运行的的困难。另外由于维护阶段持续时间很长，正在运行的软件可能是十几、二十几年前开发的，开发工具、方法、软件可能是十几、二十几年前开发的，开发工具、方法、技术与当前的工具、方法和技术差异很大，这是维护困技术与当前的工具、方法和技术差异很大，这是维护困难的另一因素。难的另一因素。 软件维护工作是一项难出成果，大家都不愿意干软件维护工作是一项难出成果，大家都不愿意干的工作。这是由于维护工作的困难性，维护工作经常遭的工作。这是由于维护工作的困难性，

24、维护工作经常遭受挫折，以及很难出成果等原因造成的。受挫折，以及很难出成果等原因造成的。 8.3 软件维护过程软件维护是一件复杂而困难的事，必须在相应的技软件维护是一件复杂而困难的事，必须在相应的技术指导下，按照一定的步骤进行。首先要建立一个维护术指导下，按照一定的步骤进行。首先要建立一个维护的组织，建立维护活动的登记、申请制度，及对维护方的组织，建立维护活动的登记、申请制度，及对维护方案的审批制度，规定复审的评价标准。案的审批制度，规定复审的评价标准。通过软件维护组织对维护过程进行有效的控制，如通过软件维护组织对维护过程进行有效的控制，如首先要对软件进行全面、准确、迅速地理解，这是决定首先要对

25、软件进行全面、准确、迅速地理解，这是决定维护工作成败和质量好坏的关键。维护工作成败和质量好坏的关键。8.3 软件维护过程8.3.1 8.3.1 维护组织维护组织软件维护阶段相对来说是漫长而且不定期的，软件维护阶段相对来说是漫长而且不定期的，长期以来很少建立正式的维护组织，然而目前人长期以来很少建立正式的维护组织，然而目前人们普遍认识到，即使对于一个小的软件开发队伍们普遍认识到，即使对于一个小的软件开发队伍而言，确立一个非正式的维护组织即非正式的维而言，确立一个非正式的维护组织即非正式的维护管理员来负责维护工作却是绝对必要的。如图护管理员来负责维护工作却是绝对必要的。如图8-1所示就是一个维护机

26、构的组织方案。所示就是一个维护机构的组织方案。8.3 软件维护过程图图8- 1 软件维护的组织结构软件维护的组织结构8.3 软件维护过程维护申请提交给一个维护管理员，他把申请交给某维护申请提交给一个维护管理员，他把申请交给某个系统监督员去评价。系统监督员是一位技术人员，他个系统监督员去评价。系统监督员是一位技术人员，他必须熟悉产品程序的某一部分。一旦做出评价，由修改必须熟悉产品程序的某一部分。一旦做出评价，由修改负责人确定如何进行修改。维护人员对程序进行修改的负责人确定如何进行修改。维护人员对程序进行修改的过程中，由配置管理员严格把关，控制修改的范围，对过程中，由配置管理员严格把关，控制修改的

27、范围，对软件配置进行审计。软件配置进行审计。维护管理员、系统监督员和修改负责人等，均代表维护管理员、系统监督员和修改负责人等，均代表维护工作的某个职责范围。修改负责人、维护管理员可维护工作的某个职责范围。修改负责人、维护管理员可以是指定的某个人，也可以是一个包括管理人员、高级以是指定的某个人，也可以是一个包括管理人员、高级技术人员在内的小组。系统监督员可以有其他职责，但技术人员在内的小组。系统监督员可以有其他职责，但应具体分管某一个软件包。应具体分管某一个软件包。8.3 软件维护过程8.3.2 8.3.2 维护工作的流程维护工作的流程图图8-2描述了实施软件维护的工作流程。第描述了实施软件维护

28、的工作流程。第一步是先确认维护要求。这需要维护人员与用户一步是先确认维护要求。这需要维护人员与用户反复协商，弄清错误概况以及对业务的影响大小，反复协商，弄清错误概况以及对业务的影响大小，以及用户希望做什么样的修改，并把这些情况存以及用户希望做什么样的修改，并把这些情况存入故障数据库。然后由维护组织管理员确认维护入故障数据库。然后由维护组织管理员确认维护类型。类型。8.3 软件维护过程图图8- 2 软件维护的工作流程图软件维护的工作流程图8.3 软件维护过程对于校正性维护申请，从评价错误的严重性开始。对于校正性维护申请，从评价错误的严重性开始。如果存在一个严重的错误，则必须安排人员，在系统监如果

29、存在一个严重的错误，则必须安排人员，在系统监督员的指导下，进行问题分析，寻找错误发生的原因，督员的指导下，进行问题分析，寻找错误发生的原因，进行进行“救火救火”性的紧急维护；对于不严重的错误，可根性的紧急维护；对于不严重的错误，可根据任务、时机情况，视轻重缓急，进行排队，统一安排据任务、时机情况，视轻重缓急，进行排队，统一安排时间。时间。所谓所谓“救火救火”式的紧急维护，是指发生的错误非常式的紧急维护，是指发生的错误非常严重，不立即修理往往会导致重大事故，这样就必须紧严重，不立即修理往往会导致重大事故，这样就必须紧急修改，暂不顾及正常的维护控制，不必考虑评价可能急修改，暂不顾及正常的维护控制，

30、不必考虑评价可能发生的副作用。在维护完成、交付用户之后再去做补偿发生的副作用。在维护完成、交付用户之后再去做补偿工作。工作。8.3 软件维护过程对于适应性维护和完善性维护申请，需要先确定每项对于适应性维护和完善性维护申请，需要先确定每项申请的优先次序。若某项申请的优先级非常高，就可立即申请的优先次序。若某项申请的优先级非常高，就可立即开始维护工作；否则，维护申请和其他的开发工作一样，开始维护工作；否则，维护申请和其他的开发工作一样，进行排队，统一安排时间。并不是所有的完善性维护申请进行排队，统一安排时间。并不是所有的完善性维护申请都必须承担，因为进行完善性维护等于是做二次开发，工都必须承担，因

31、为进行完善性维护等于是做二次开发，工作量很大，需要根据商业需要、可利用资源的情况、目前作量很大，需要根据商业需要、可利用资源的情况、目前和将来软件的发展方向以及其他的考虑，决定是否承担。和将来软件的发展方向以及其他的考虑，决定是否承担。虽然维护申请的类型不同，但都要进行同样的技术工虽然维护申请的类型不同，但都要进行同样的技术工作。这些工作有：修改软件需求说明、修改软件设计、设作。这些工作有：修改软件需求说明、修改软件设计、设计评审、对源程序做必要的修改、单元测试、集成测试计评审、对源程序做必要的修改、单元测试、集成测试(回归测试回归测试)、确认测试、软件配置评审等。、确认测试、软件配置评审等。

32、8.3 软件维护过程在每次软件维护任务完成后，要对维护任务进行复在每次软件维护任务完成后，要对维护任务进行复审。进行复审时要回答下列问题：审。进行复审时要回答下列问题：(1) 在目前情况下，设计、编码和测试中的哪一方在目前情况下，设计、编码和测试中的哪一方面可以改进？面可以改进？(2) 各种维护资源已经用了哪些？还有哪些未用各种维护资源已经用了哪些？还有哪些未用(3) 工作中主要的或次要的障碍是什么？工作中主要的或次要的障碍是什么？(4) 从维护申请的类型来看是否应当有预防性维护？从维护申请的类型来看是否应当有预防性维护？情况复审对将来的维护工作如何进行会产生重要的情况复审对将来的维护工作如何

33、进行会产生重要的影响，并可为软件机构的有效管理提供重要的反馈信息。影响，并可为软件机构的有效管理提供重要的反馈信息。8.3 软件维护过程8.3.3 8.3.3 维护技术维护技术有两类维护技术，它们是面向维护的技术和有两类维护技术，它们是面向维护的技术和维护支援技术。面向维护的技术是在软件开发阶维护支援技术。面向维护的技术是在软件开发阶段用来减少错误、提高软件可维护性的技术。维段用来减少错误、提高软件可维护性的技术。维护支援技术是在软件维护阶段用来提高维护工作护支援技术是在软件维护阶段用来提高维护工作的效率和质量的技术。的效率和质量的技术。(1) 面向维护的技术面向维护的技术面向维护的技术涉及软

34、件开发的所有阶段。面向维护的技术涉及软件开发的所有阶段。8.3 软件维护过程在需求分析阶段，对用户的需求进行严格的分析定义，在需求分析阶段，对用户的需求进行严格的分析定义，使之没有矛盾和易于理解，可以减少软件中的错误。例如使之没有矛盾和易于理解，可以减少软件中的错误。例如美国密执安大学的美国密执安大学的ISDOS系统就是需求分析阶段使用的系统就是需求分析阶段使用的一种分析与文档化工具，可以用它来检查需求说明书的一一种分析与文档化工具，可以用它来检查需求说明书的一致性和完备性。致性和完备性。在设计阶段，划分模块时充分考虑将来改动或扩充的在设计阶段，划分模块时充分考虑将来改动或扩充的可能性。使用结

35、构化分析和结构化设计方法，采用容易变可能性。使用结构化分析和结构化设计方法，采用容易变更的、不依赖于特定硬件和特定操作系统的设计。更的、不依赖于特定硬件和特定操作系统的设计。在编码阶段，采用灵活的数据结构。使程序相对独立在编码阶段，采用灵活的数据结构。使程序相对独立于数据的物理结构，养成良好的编程风格。于数据的物理结构，养成良好的编程风格。在测试阶段，尽可能多的发现错误，保存测试用例和在测试阶段，尽可能多的发现错误，保存测试用例和测试数据等。测试数据等。8.3 软件维护过程(2) 维护支援技术：包括以下各方面的技术。维护支援技术：包括以下各方面的技术。 信息收集。信息收集。 错误原因分析。错误

36、原因分析。 软件分析与理解。软件分析与理解。 维护方案评价。维护方案评价。 代码与文档修改。代码与文档修改。 修改后的确认。修改后的确认。 远距离的维护。远距离的维护。 8.4 软件的可维护性许多软件的维护很困难，这是因为软件的源许多软件的维护很困难，这是因为软件的源程序和文档难于理解和修改，造成软件维护工作程序和文档难于理解和修改，造成软件维护工作量大、成本量大、成本 上升、修改出错率高。由于维护工上升、修改出错率高。由于维护工作面广，维护的难度大，稍有不慎就会在修改中作面广，维护的难度大，稍有不慎就会在修改中给软件带来新的问题或引入新的错误，所以为了给软件带来新的问题或引入新的错误，所以为

37、了使得软件能够易于维护，必须考虑使软件具有可使得软件能够易于维护，必须考虑使软件具有可维护性。维护性。8.4 软件的可维护性8.4.1 8.4.1 软件可维护性的定义软件可维护性的定义软件可维护性是指软件能够被理解，并能纠正软件软件可维护性是指软件能够被理解，并能纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。扩充或压缩的容易程度。软件的可维护性、可使用性和可靠性是衡量软件质软件的可维护性、可使用性和可靠性是衡量软件质量的几个主要特性，也是用户十分关心的问题之一。但量的几个主要特性，也是用户十分关心的问题之一。但

38、是影响软件质量的这些因素，目前还没有普遍适用的定是影响软件质量的这些因素，目前还没有普遍适用的定量度量的方法。量度量的方法。8.4 软件的可维护性软件的可维护性是软件开发阶段各个时期的关键目标。软件的可维护性是软件开发阶段各个时期的关键目标。影响软件可维护性的因素很多，设计、编码和测试中的疏忽影响软件可维护性的因素很多，设计、编码和测试中的疏忽和低劣的软件配置，缺少文档等都对软件的可维护性产生不和低劣的软件配置，缺少文档等都对软件的可维护性产生不良影响。软件维护可用如下的七个质量特性来衡量，即可理良影响。软件维护可用如下的七个质量特性来衡量，即可理解性、可测试性、可修改性、可靠性、可移植性、可

39、使用性解性、可测试性、可修改性、可靠性、可移植性、可使用性和效率。而且对于不同类型的维护，这七种特性的侧重点也和效率。而且对于不同类型的维护，这七种特性的侧重点也不相同。这些质量特性通常体现在软件产品的许多方面。将不相同。这些质量特性通常体现在软件产品的许多方面。将这些特性作为基本要求，需要在软件开发的整个阶段都采用这些特性作为基本要求，需要在软件开发的整个阶段都采用相应的措施保证，也就是说这些质量要求渗透到软件开发的相应的措施保证，也就是说这些质量要求渗透到软件开发的各个步骤中。因此，软件的可维护性是产品投入运行以前各各个步骤中。因此，软件的可维护性是产品投入运行以前各阶段面临这七种质量特性

40、要求进行开发的最终结果。阶段面临这七种质量特性要求进行开发的最终结果。8.4 软件的可维护性表表8- 1 各类维护中的侧重点各类维护中的侧重点表表8-1列出了在各类维护中应侧重哪些特性。列出了在各类维护中应侧重哪些特性。8.4 软件的可维护性8.4.2 8.4.2 可维护性的度量可维护性的度量目前有几种对软件可维护性进行综合度量的方法，但目前有几种对软件可维护性进行综合度量的方法，但要对可维护性做出定量度量还是较困难的。这里介绍度量要对可维护性做出定量度量还是较困难的。这里介绍度量一个可维护的软件的七种特性时常用的方法，即质量检查一个可维护的软件的七种特性时常用的方法，即质量检查表、质量测试和

41、质量标准。表、质量测试和质量标准。质量检查表用于测试程序中某些质量特性是否存在的质量检查表用于测试程序中某些质量特性是否存在的一个问题清单。评测者针对检查表上的每一个问题，依据一个问题清单。评测者针对检查表上的每一个问题，依据自己的定性判断，回答自己的定性判断，回答“是是”或者或者“否否”。质量测试和质。质量测试和质量标准用于定量分析和评价程序的质量。量标准用于定量分析和评价程序的质量。由于许多质量特性是相互抵触的，要考虑几种不同的由于许多质量特性是相互抵触的，要考虑几种不同的度量标准，去度量不同的质量特性。度量标准，去度量不同的质量特性。8.4 软件的可维护性1. 可理解性可理解性可理解性表

42、明人们通过阅读源代码和相关文档，了可理解性表明人们通过阅读源代码和相关文档，了解软件功能及其运行状况的容易程度。一个可理解的软解软件功能及其运行状况的容易程度。一个可理解的软件主要应该具备的以下特性：模块化，风格一致性，使件主要应该具备的以下特性：模块化，风格一致性，使用清晰明确的代码，使用有意义的数据名和过程名，结用清晰明确的代码，使用有意义的数据名和过程名，结构化，完整性等。构化，完整性等。对于可理解性，可以使用一种叫做对于可理解性，可以使用一种叫做“90-10测试法测试法”来衡量。即让有经验的程序员阅读来衡量。即让有经验的程序员阅读10分钟要测试的程序，分钟要测试的程序，然后把这个程序拿

43、开，这个程序员如能凭记忆和理解写然后把这个程序拿开，这个程序员如能凭记忆和理解写出出90的程序，则称该程序是可理解的。的程序，则称该程序是可理解的。8.4 软件的可维护性2. 可靠性可靠性可靠性表明一个软件按照用户的要求和设计目标，在给可靠性表明一个软件按照用户的要求和设计目标，在给定的一段时间内正确执行的概率。可靠性的主要度量标准有：定的一段时间内正确执行的概率。可靠性的主要度量标准有：平均失效间隔时间、平均修复时间、有效性。度量可靠性的平均失效间隔时间、平均修复时间、有效性。度量可靠性的方法，主要有两类：方法，主要有两类：(1) 根据软件错误统计数字，进行可靠性预测。可利用根据软件错误统计

44、数字，进行可靠性预测。可利用一些可靠性模型，根据程序测试时发现并排除的错误数预测一些可靠性模型，根据程序测试时发现并排除的错误数预测平均失效间隔时间。平均失效间隔时间。(2) 根据软件复杂性，预测软件可靠性。使用这种方法根据软件复杂性，预测软件可靠性。使用这种方法的前提条件是可靠性与复杂性有关。程序复杂性度量标准可的前提条件是可靠性与复杂性有关。程序复杂性度量标准可用于预测哪些模块最可能发生错误，以及可能出现的错误类用于预测哪些模块最可能发生错误，以及可能出现的错误类型，了解错误类型及它们可能出现在哪里，能更快地查出和型，了解错误类型及它们可能出现在哪里，能更快地查出和纠正更多的错误，提高可靠

45、性。纠正更多的错误，提高可靠性。8.4 软件的可维护性3. 可测试性可测试性可测试性表明论证软件正确性的容易程度。程序越可测试性表明论证软件正确性的容易程度。程序越简单，验证其正确性就越容易。对于软件中的程序模块，简单，验证其正确性就越容易。对于软件中的程序模块，可用程序复杂性来度量可测试性。显然，程序的环路复可用程序复杂性来度量可测试性。显然，程序的环路复杂性越大，程序的路径就越多，全面测试程序的难度就杂性越大，程序的路径就越多，全面测试程序的难度就越大。越大。4. 可修改性可修改性可修改性表明软件容易修改的程度。一个可修改的可修改性表明软件容易修改的程度。一个可修改的软件应当是可理解的、通

46、用的、灵活的、简单的。其中，软件应当是可理解的、通用的、灵活的、简单的。其中，通用是指当软件适用的功能发生改变而无需修改。灵活通用是指当软件适用的功能发生改变而无需修改。灵活指很容易对软件进行修改。指很容易对软件进行修改。8.4 软件的可维护性测试可修改性的一种定量方法是修改练习。基本思想是测试可修改性的一种定量方法是修改练习。基本思想是通过做几个简单的修改，来评价修改难度。设通过做几个简单的修改，来评价修改难度。设C是程序中各是程序中各个模块的平均复杂性，个模块的平均复杂性，A是必须修改的模块数，是必须修改的模块数，D是要修改是要修改的模块的平均复杂性。则修改的难度公式为：的模块的平均复杂性

47、。则修改的难度公式为：D=A/C在简单修改时当在简单修改时当D1，说明该软件修改困难。，说明该软件修改困难。A和和C可用可用任何一种度量程序复杂性的方法计算。任何一种度量程序复杂性的方法计算。5. 可移植性可移植性表明软件转移到一个新的计算环境的可能性的大小，或表明软件转移到一个新的计算环境的可能性的大小，或者表明软件能有效地在各种环境中运行的容易程度。一个可者表明软件能有效地在各种环境中运行的容易程度。一个可移植性好的软件应具有良好、灵活、不依赖于某一具体计算移植性好的软件应具有良好、灵活、不依赖于某一具体计算机或操作系统的性能。机或操作系统的性能。8.4 软件的可维护性6. 效率效率效率表

48、明一个软件能执行预定功能而又不浪效率表明一个软件能执行预定功能而又不浪费机器资源的程度，这些资源包括：内存容量、费机器资源的程度，这些资源包括：内存容量、外存容量、通道容量和执行时间。外存容量、通道容量和执行时间。7. 可使用性可使用性站在用户的角度，可使用性是软件方便、实站在用户的角度，可使用性是软件方便、实用、及易于使用的程度。一个可使用的程序应该用、及易于使用的程度。一个可使用的程序应该易于使用、允许出错和修改，而尽可能保证用户易于使用、允许出错和修改，而尽可能保证用户在使用时不陷入混乱状态。在使用时不陷入混乱状态。8.4 软件的可维护性8.4.3 8.4.3 提高可维护性的方法提高可维

49、护性的方法软件的可维护性对于延长软件的生存期具有软件的可维护性对于延长软件的生存期具有决定意义，因此必须考虑怎样才能提高软件的可决定意义，因此必须考虑怎样才能提高软件的可维护性。为此，可从以下五个方面着手。维护性。为此，可从以下五个方面着手。8.4 软件的可维护性1. 建立明确的软件质量目标建立明确的软件质量目标如果要程序完全满足可维护性的七种质量特性，需要付如果要程序完全满足可维护性的七种质量特性，需要付出很大的代价，而且也不一定行得通。实际上，某些质量特出很大的代价，而且也不一定行得通。实际上，某些质量特性是相互促进的，如可理解性和可测试性，可理解性和可修性是相互促进的，如可理解性和可测试

50、性，可理解性和可修改性；某些质量特性是相互抵触的，如效率和可移植性，效改性；某些质量特性是相互抵触的，如效率和可移植性，效率和可修改性。因此，为保证程序的可维护性，应该在一定率和可修改性。因此，为保证程序的可维护性，应该在一定程度上满足可维护的各个特性，但各个特性的重要性又是随程度上满足可维护的各个特性，但各个特性的重要性又是随着程序的用途或计算机环境的不同而改变的。对编译程序来着程序的用途或计算机环境的不同而改变的。对编译程序来说，效率和可移植性是主要的；对信息管理系统来说，可使说，效率和可移植性是主要的；对信息管理系统来说，可使用性和可修改性可能是主要的。所以在对程序的质量特性提用性和可修

51、改性可能是主要的。所以在对程序的质量特性提出目标的同时，还必须规定它们的优先级。出目标的同时，还必须规定它们的优先级。8.4 软件的可维护性2. 使用先进的软件开发技术和工具使用先进的软件开发技术和工具利用先进的软件开发技术是软件开发过程中利用先进的软件开发技术是软件开发过程中提高软件质量，降低成本的有效方法之一，也是提高软件质量，降低成本的有效方法之一，也是提高可维护性的有效的技术。常用的技术有：模提高可维护性的有效的技术。常用的技术有：模块化、结构化程序设计，自动重建结构和重新格块化、结构化程序设计，自动重建结构和重新格式化的工具等。例如，面向对象的软件开发方法式化的工具等。例如，面向对象

52、的软件开发方法就是一个非常使用而强有力的软件开发方法。就是一个非常使用而强有力的软件开发方法。8.4 软件的可维护性3. 进行明确的质量保证审查进行明确的质量保证审查质量保证审查对于获得和维持软件的质量，是一个很有质量保证审查对于获得和维持软件的质量，是一个很有用的技术。除了保证软件得到适当的质量外，审查还可以用用的技术。除了保证软件得到适当的质量外，审查还可以用来检测在开发和维护阶段内发生的质量变化。一旦检测出问来检测在开发和维护阶段内发生的质量变化。一旦检测出问题，就可以采取措施进行纠正，以控制不断增长的软件维护题，就可以采取措施进行纠正，以控制不断增长的软件维护成本，延长软件系统的有效生

53、命期。成本，延长软件系统的有效生命期。在软件开发和软件维护的各阶段，质量保证检查是非常在软件开发和软件维护的各阶段，质量保证检查是非常有效的方法。保证软件质量的最佳方法就是在软件开发的最有效的方法。保证软件质量的最佳方法就是在软件开发的最初阶段就把质量和可维护性要求考虑进去，并在开发过程每初阶段就把质量和可维护性要求考虑进去，并在开发过程每一阶段的终点，设置检查点进行检查。检查的目的是要证实，一阶段的终点，设置检查点进行检查。检查的目的是要证实，已开发的软件是否符合标准，是否满足规定的质量需求。在已开发的软件是否符合标准，是否满足规定的质量需求。在不同的检查点，检查的重点不完全相同，如图不同的

54、检查点，检查的重点不完全相同，如图8-3所示。所示。8.4 软件的可维护性图图8- 3 软件开发期间各个检查点的检查重点软件开发期间各个检查点的检查重点8.4 软件的可维护性例如在设计阶段，检查重点是可理解性、可修改性、可例如在设计阶段，检查重点是可理解性、可修改性、可测试性，可理解性检查的重点是程序的复杂性。测试性，可理解性检查的重点是程序的复杂性。4. 验收检查验收检查验收检查是一个特殊的检查点的检查，它实际上是验收验收检查是一个特殊的检查点的检查，它实际上是验收测试的一部分，它是把软件从开发转移到维护的最后一次检测试的一部分，它是把软件从开发转移到维护的最后一次检查查,是软件投入运行之前

55、保证可维护性的最后机会。它对减是软件投入运行之前保证可维护性的最后机会。它对减少维护费用，提高软件质量非常重要。少维护费用，提高软件质量非常重要。 需求和规范标准：以需求规格说明书为标准，进行检需求和规范标准：以需求规格说明书为标准，进行检查，区分必须的、任选的、将来的需求；包括对系统运行时查，区分必须的、任选的、将来的需求；包括对系统运行时的计算机设备的需求；对维护、测试、操作、以及维护人员的计算机设备的需求；对维护、测试、操作、以及维护人员的需求；对测试工具等的需求。的需求；对测试工具等的需求。8.4 软件的可维护性 设计标准软件应设计成分层的模块结构。每个模块设计标准软件应设计成分层的模

56、块结构。每个模块应完成独立的功能，满足高内聚、低耦合的原则。通过一应完成独立的功能，满足高内聚、低耦合的原则。通过一些知道预期变化的实例，说明设计的可扩充性、可缩减性些知道预期变化的实例，说明设计的可扩充性、可缩减性和可适应性。和可适应性。 源代码标准尽可能使用最高级的程序设计语言，且源代码标准尽可能使用最高级的程序设计语言，且只使用语言的标准版本；所有的代码都必须具有良好的结只使用语言的标准版本；所有的代码都必须具有良好的结构；所有的代码都必须文档化，在注释中说明它的输入、构；所有的代码都必须文档化，在注释中说明它的输入、输出以及便于测试、再测试的一些特点与风格。输出以及便于测试、再测试的一

57、些特点与风格。 文档标准：文档中应说明程序的输入文档标准：文档中应说明程序的输入/输出、使用输出、使用方法方法/算法、错误恢复方法、所有参数的范围以及缺省条算法、错误恢复方法、所有参数的范围以及缺省条件等。件等。8.4 软件的可维护性5. 周期性的维护检查周期性的维护检查上述两种软件检查可用来保证新的软件系统的可维护上述两种软件检查可用来保证新的软件系统的可维护性。对已运行的软件应该进行周期性的维护检查。软件在性。对已运行的软件应该进行周期性的维护检查。软件在运行期间，为了纠正在开发阶段未发现的错误和缺陷，使运行期间，为了纠正在开发阶段未发现的错误和缺陷，使软件适应新的计算机环境并满足变化的用

58、户要求，必须对软件适应新的计算机环境并满足变化的用户要求，必须对正在使用的软件进行修改。修改软件可能引入新的错误并正在使用的软件进行修改。修改软件可能引入新的错误并破坏原来程序概念的完整性。因此，必须像硬件的定期检破坏原来程序概念的完整性。因此，必须像硬件的定期检查一样，每月一次，或两月一次，对软件做周期性的维护查一样，每月一次，或两月一次，对软件做周期性的维护审查，以跟踪软件质量的变化。审查，以跟踪软件质量的变化。周期性维护审查实际上是开发阶段检查点复查的继续，周期性维护审查实际上是开发阶段检查点复查的继续，并且采用的检查方法、检查内容都是相同的。并且采用的检查方法、检查内容都是相同的。8.

59、4 软件的可维护性6. 选择可维护的程序设计语言选择可维护的程序设计语言程序设计语言的选择的不同，对程序的可维护性影程序设计语言的选择的不同，对程序的可维护性影响很大。很明显，低级语言很难理解和掌握，维护当然响很大。很明显，低级语言很难理解和掌握，维护当然很困难。高级语言比低级语言更容易理解，但同是高级很困难。高级语言比低级语言更容易理解，但同是高级语言，可理解的程度也不一样。例如，用户使用第四代语言，可理解的程度也不一样。例如，用户使用第四代语言开发商业应用程序比使用通常的高级语言快很多倍。语言开发商业应用程序比使用通常的高级语言快很多倍。一些第四代语言是过程语言，而另一些是非过程语言。一些

60、第四代语言是过程语言，而另一些是非过程语言。对非过程语言，用户不需要指出实现算法，只需向编译对非过程语言，用户不需要指出实现算法，只需向编译程序或解释程序提出自己的要求。例如它能自动选择报程序或解释程序提出自己的要求。例如它能自动选择报表格式、文字字符类型等。另外，第四代语言容易理解，表格式、文字字符类型等。另外，第四代语言容易理解，容易编程，程序容易修改，从维护角度来看，第四代语容易编程，程序容易修改，从维护角度来看，第四代语言就比其他语言更容易维护。言就比其他语言更容易维护。8.4 软件的可维护性7. 健全程序的文档健全程序的文档(1) 程序文档程序文档程序文档是对程序的总目标、程序的各组