软件工程导论第8章.ppt

《软件工程导论第8章.ppt》由会员分享，可在线阅读，更多相关《软件工程导论第8章.ppt（67页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第第8章章 维护维护8.1 软件维护的定义软件维护的定义8.2 软件维护的特点软件维护的特点8.3 软件维护过程软件维护过程8.4 软件的可维护性软件的可维护性8.5 预防性维护预防性维护8.6 软件再工程过程软件再工程过程8.7 小结小结习题习题在软件产品被开发出来并交付用户使用之后，就进入在软件产品被开发出来并交付用户使用之后，就进入了软件的运行维护阶段。这个阶段是软件生命周期的了软件的运行维护阶段。这个阶段是软件生命周期的最后一个阶段，其基本任务是保证软件在最后一个阶段，其基本任务是保证软件在一个相当长一个相当长的时期的时期能够正常运行。能够正常运行。软件维护需要的工作量很大，平均说来，

2、大型软件的软件维护需要的工作量很大，平均说来，大型软件的维护成本高达开发成本的维护成本高达开发成本的4倍左右。目前国外许多软倍左右。目前国外许多软件开发组织把件开发组织把60%以上的人力用于维护已有的软件，以上的人力用于维护已有的软件，而且随着软件数量增多和使用寿命延长，这个百分比而且随着软件数量增多和使用寿命延长，这个百分比还在持续上升。将来维护工作甚至可能会束缚住软件还在持续上升。将来维护工作甚至可能会束缚住软件开发组织的手脚，使他们没有余力开发新的软件。开发组织的手脚，使他们没有余力开发新的软件。软件工程的目的是要提高软件的可维护性，减少软件软件工程的目的是要提高软件的可维护性，减少软件

3、维护所需要的工作量，降低软件系统的总成本。维护所需要的工作量，降低软件系统的总成本。所谓软件维护就是在软件已经交付使用之后，为了改所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。可以通过正错误或满足新的需要而修改软件的过程。可以通过描述软件交付使用后可能进行的描述软件交付使用后可能进行的4项活动，具体地定项活动，具体地定义软件维护。义软件维护。因为软件测试不可能暴露出一个大型软件系统中所有因为软件测试不可能暴露出一个大型软件系统中所有潜藏的错误，所以必然会有第一项维护活动：在任何潜藏的错误，所以必然会有第一项维护活动：在任何大型程序的使用期间，用户必然会发现

4、程序错误，并大型程序的使用期间，用户必然会发现程序错误，并且把他们遇到的问题报告给维护人员。把诊断和改正且把他们遇到的问题报告给维护人员。把诊断和改正错误的过程称为改正性维护。错误的过程称为改正性维护。8.1 软件维护的定义软件维护的定义计算机科学技术领域的各个方面都在迅速进步，大约计算机科学技术领域的各个方面都在迅速进步，大约每过每过36个月就有新一代的硬件宣告出现，经常推出新个月就有新一代的硬件宣告出现，经常推出新操作系统或旧系统的修改版本，时常增加或修改外部操作系统或旧系统的修改版本，时常增加或修改外部设备和其他系统部件；另一方面，应用软件的使用寿设备和其他系统部件；另一方面，应用软件的

5、使用寿命却很容易超过命却很容易超过10年，远远长于最初开发这个软件时年，远远长于最初开发这个软件时的运行环境的寿命。因此，适应性维护，也就是为了的运行环境的寿命。因此，适应性维护，也就是为了和变化了的环境适当地配合而进行的修改软件的活动，和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动。是既必要又经常的维护活动。当一个软件系统顺利地运行时，常常出现第三项维护当一个软件系统顺利地运行时，常常出现第三项维护活动：在使用软件的过程中用户往往提出增加新功能活动：在使用软件的过程中用户往往提出增加新功能或修改已有功能的建议，还可能提出一般性的改进意或修改已有功能的建议，还可能提出

6、一般性的改进意见。为了满足这类要求，需要进行完善性维护。这项见。为了满足这类要求，需要进行完善性维护。这项维护活动通常占软件维护工作的大部分。维护活动通常占软件维护工作的大部分。当为了改进未来的可维护性或可靠性，或为了给未来当为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件时，出现了第四项的改进奠定更好的基础而修改软件时，出现了第四项维护活动。这项维护活动通常称为预防性维护，目前维护活动。这项维护活动通常称为预防性维护，目前这项维护活动相对比较少。这项维护活动相对比较少。从上述关于软件维护的定义不难看出，软件维护绝不从上述关于软件维护的定义不难看出，软件维护绝不仅限于

7、纠正使用中发现的错误，事实上在全部维护活仅限于纠正使用中发现的错误，事实上在全部维护活动中一半以上是完善性维护。国外的统计数字表明，动中一半以上是完善性维护。国外的统计数字表明，完善性维护占全部维护活动的完善性维护占全部维护活动的50%66%，改正性维，改正性维护占护占17%21%，适应性维护占，适应性维护占18%25%，其他维，其他维护活动只占护活动只占4%左右。左右。应该注意，上述应该注意，上述4类维护活动都必须应用于整个软件类维护活动都必须应用于整个软件配置，维护软件文档和维护软件的可执行代码是同样配置，维护软件文档和维护软件的可执行代码是同样重要的。重要的。1.非结构化维护非结构化维护

8、8.2 软件维护的特点软件维护的特点 8.2.1 结构化维护与非结构化维护差别巨大结构化维护与非结构化维护差别巨大如果软件配置的惟一成分是程序代码如果软件配置的惟一成分是程序代码，那么维护活动，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难，对于软件结构、全程数据文档不足而使评价更困难，对于软件结构、全程数据结构、系统接口、性能和结构、系统接口、性能和(或或)设计约束等经常会产生设计约束等经常会产生误解，而且对程序代码所做的改动的后果也是难于估误解，而且对程序代码所做的改动的后果也是难于估量的：因为没有测试方面的文

9、档，所以不可能进行回量的：因为没有测试方面的文档，所以不可能进行回归测试归测试(即指为了保证所做的修改没有在以前可以正即指为了保证所做的修改没有在以前可以正常使用的软件功能中引入错误而重复过去做过的测试常使用的软件功能中引入错误而重复过去做过的测试)。非结构化维护需要付出很大代价。非结构化维护需要付出很大代价(浪费精力并且遭浪费精力并且遭受挫折的打击受挫折的打击)，这种维护方式是没有使用良好定义，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。的方法学开发出来的软件的必然结果。2.结构化维护结构化维护如果有一个完整的软件配置存在如果有一个完整的软件配置存在，那么维护工作从评，那

10、么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特价设计文档开始，确定软件重要的结构特点、性能特点以及接口特点；估量要求的改动将带来的影响，并点以及接口特点；估量要求的改动将带来的影响，并且计划实施途径。然后首先修改设计并且对所做的修且计划实施途径。然后首先修改设计并且对所做的修改进行仔细复查。接下来编写相应的源程序代码；使改进行仔细复查。接下来编写相应的源程序代码；使用在测试说明书中包含的信息进行回归测试；最后，用在测试说明书中包含的信息进行回归测试；最后，把修改后的软件再次交付使用。把修改后的软件再次交付使用。刚才描述的事件构成结构化维护，它是在软件开发的刚才描述的事件构成结构化

11、维护，它是在软件开发的早期应用软件工程方法学的结果。虽然有了软件的完早期应用软件工程方法学的结果。虽然有了软件的完整配置并不能保证维护中没有问题，但是确实能减少整配置并不能保证维护中没有问题，但是确实能减少精力的浪费并且能提高维护的总体质量。精力的浪费并且能提高维护的总体质量。在过去的几十年中，软件维护的费用稳步上升。在过去的几十年中，软件维护的费用稳步上升。1970年用于维护已有软件的费用只占软件总预算的年用于维护已有软件的费用只占软件总预算的35%40%，1980年上升为年上升为40%60%，1990年上升为年上升为70%80%。维护费用只不过是软件维护的最明显的代价，其他一维护费用只不过

12、是软件维护的最明显的代价，其他一些现在还不明显的代价将来可能更为人们所关注。因些现在还不明显的代价将来可能更为人们所关注。因为可用的资源必须供维护任务使用，以致耽误甚至丧为可用的资源必须供维护任务使用，以致耽误甚至丧失了开发的良机，这是软件维护的一个无形的代价。失了开发的良机，这是软件维护的一个无形的代价。其他无形的代价还有：其他无形的代价还有：8.2.2 维护的代价高昂维护的代价高昂当看来合理的有关改错或修改的要求不能及时满足时当看来合理的有关改错或修改的要求不能及时满足时将引起用户不满；将引起用户不满；由于维护时的改动，在软件中引入了潜伏的错误，从由于维护时的改动，在软件中引入了潜伏的错误

13、，从而降低了软件的质量；而降低了软件的质量；当必须把软件工程师调去从事维护工作时，将在开发当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱。过程中造成混乱。软件维护的最后一个代价是生产率的大幅度下降，这软件维护的最后一个代价是生产率的大幅度下降，这种情况在维护旧程序时常常遇到。种情况在维护旧程序时常常遇到。用于维护工作的劳动可以分成生产性活动用于维护工作的劳动可以分成生产性活动(例如，分例如，分析评价，修改设计和编写程序代码等析评价，修改设计和编写程序代码等)和非生产性活和非生产性活动动(例如，理解程序代码的功能，解释数据结构、接例如，理解程序代码的功能，解释数据结构、接口特点和性

14、能限度等口特点和性能限度等)。下述表达式给出维护工作量。下述表达式给出维护工作量的一个模型：的一个模型：M=P+Kexp(c-d)其中：其中：M是维护用的总工作量，是维护用的总工作量，P是生产性工作量，是生产性工作量，K是经验常数，是经验常数，c是复杂程度是复杂程度(非结构化设计和缺少文非结构化设计和缺少文档都会增加软件的复杂程度档都会增加软件的复杂程度)，d是维护人员对软件的是维护人员对软件的熟悉程度。熟悉程度。上面的模型表明，如果软件的开发途径不好上面的模型表明，如果软件的开发途径不好(即，没即，没有使用软件工程方法学有使用软件工程方法学)，而且原来的开发人员不能，而且原来的开发人员不能参

15、加维护工作，那么维护工作量和费用将指数地增加。参加维护工作，那么维护工作量和费用将指数地增加。与软件维护有关的绝大多数问题，都可归因于软件定与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺点。在软件生命周期的头两义和软件开发的方法有缺点。在软件生命周期的头两个时期没有严格而又科学的管理和规划，几乎必然会个时期没有严格而又科学的管理和规划，几乎必然会导致在最后阶段出现问题。下面列出和软件维护有关导致在最后阶段出现问题。下面列出和软件维护有关的部分问题：的部分问题：（1）理解别人写的程序通常非常困难，而且困难程理解别人写的程序通常非常困难，而且困难程度随着软件配置成分的减少而迅

16、速增加。如果仅有程度随着软件配置成分的减少而迅速增加。如果仅有程序代码没有说明文档，则会出现严重的问题。序代码没有说明文档，则会出现严重的问题。8.2.3 维护的问题很多维护的问题很多（2）需要维护的软件往往没有合格的文档，或者文需要维护的软件往往没有合格的文档，或者文档资料显著不足。认识到软件必须有文档仅仅是第一档资料显著不足。认识到软件必须有文档仅仅是第一步，容易理解的并且和程序代码完全一致的文档才真步，容易理解的并且和程序代码完全一致的文档才真正有价值。正有价值。（3）当要求对软件进行维护时，不能指望由开发人当要求对软件进行维护时，不能指望由开发人员给我们仔细说明软件。由于维护阶段持续的

17、时间很员给我们仔细说明软件。由于维护阶段持续的时间很长，因此，当需要解释软件时，往往原来写程序的人长，因此，当需要解释软件时，往往原来写程序的人已经不在附近了。已经不在附近了。（4）绝大多数软件在设计时没有考虑将来的修改。绝大多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理的设计方法学，否则修改除非使用强调模块独立原理的设计方法学，否则修改软件既困难又容易发生差错。软件既困难又容易发生差错。（5）软件维护不是一项吸引人的工作。形成这种观软件维护不是一项吸引人的工作。形成这种观念很大程度上是因为维护工作经常遭受挫折。念很大程度上是因为维护工作经常遭受挫折。上述种种问题在现有的没采用软

18、件工程思想开发出来上述种种问题在现有的没采用软件工程思想开发出来的软件中，都或多或少地存在着。不应该把一种科学的软件中，都或多或少地存在着。不应该把一种科学的方法学看做万应灵药，但是，软件工程至少部分地的方法学看做万应灵药，但是，软件工程至少部分地解决了与维护有关的每一个问题。解决了与维护有关的每一个问题。维护过程本质上是修改和压缩了的软件定义和开发过维护过程本质上是修改和压缩了的软件定义和开发过程，而且事实上远在提出一项维护要求之前，与软件程，而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。首先必须建立一个维护维护有关的工作已经开始了。首先必须建立一个维护组织，随后必须确

19、定报告和评价的过程，而且必须为组织，随后必须确定报告和评价的过程，而且必须为每个维护要求规定一个标准化的事件序列。此外，还每个维护要求规定一个标准化的事件序列。此外，还应该建立一个适用于维护活动的记录保管过程，并且应该建立一个适用于维护活动的记录保管过程，并且规定复审标准。规定复审标准。8.3 软件维护过程软件维护过程1.维护组织维护组织虽然通常并不需要建立正式的维护组织，但是，即使虽然通常并不需要建立正式的维护组织，但是，即使对于一个小的软件开发团体而言，非正式地委托责任对于一个小的软件开发团体而言，非正式地委托责任也是绝对必要的。每个维护要求都通过也是绝对必要的。每个维护要求都通过维护管理

20、员维护管理员转转交给相应的交给相应的系统管理员系统管理员去评价。系统管理员是被指定去评价。系统管理员是被指定去熟悉一小部分产品程序的技术人员。系统管理员对去熟悉一小部分产品程序的技术人员。系统管理员对维护任务做出评价之后，由维护任务做出评价之后，由变化授权人变化授权人决定应该进行决定应该进行的活动。图的活动。图8.1描绘了上述组织方式。描绘了上述组织方式。在维护活动开始之前就明确维护责任是十分必要的，在维护活动开始之前就明确维护责任是十分必要的，这样做可以大大减少维护过程中可能出现的混乱。这样做可以大大减少维护过程中可能出现的混乱。图图8.1 维护组织维护组织2.维护报告维护报告应该应该用标准

21、化的格式表达所有软件维护要求用标准化的格式表达所有软件维护要求。软件维。软件维护人员通常给用户提供空白的维护要求表护人员通常给用户提供空白的维护要求表有时称有时称为软件问题报告表，这个表格由要求一项维护活动的为软件问题报告表，这个表格由要求一项维护活动的用户填写。如果遇到了一个错误，那么必须完整描述用户填写。如果遇到了一个错误，那么必须完整描述导致出现错误的环境导致出现错误的环境(包括输入数据、全部输出数据包括输入数据、全部输出数据以及其他有关信息以及其他有关信息)。对于适应性或完善性的维护要。对于适应性或完善性的维护要求，应该提出一个简短的需求说明书。如前所述，由求，应该提出一个简短的需求说

22、明书。如前所述，由维护管理员和系统管理员评价用户提交的维护要求表。维护管理员和系统管理员评价用户提交的维护要求表。维护要求表是一个外部产生的文件，它是计划维护活维护要求表是一个外部产生的文件，它是计划维护活动的基础。软件组织内部应该制定出一个软件修改报动的基础。软件组织内部应该制定出一个软件修改报告，告，它给出下述信息它给出下述信息：(1)满足维护要求表中提出的要求所需要的工作量；满足维护要求表中提出的要求所需要的工作量；(2)维护要求的性质；维护要求的性质；(3)这项要求的优先次序；这项要求的优先次序；(4)与修改有关的事后数据。与修改有关的事后数据。在拟定进一步的维护计划之前，把软件修改报

23、告提交在拟定进一步的维护计划之前，把软件修改报告提交给变化授权人审查批准。给变化授权人审查批准。3.维护的事件流维护的事件流图图8.2描绘了由一项维护要求而引出的一串事件。首描绘了由一项维护要求而引出的一串事件。首先应该确定要求进行的维护的类型。用户常常把一项先应该确定要求进行的维护的类型。用户常常把一项要求看作是为了改正软件的错误要求看作是为了改正软件的错误(改正性维护改正性维护)，而开，而开发人员可能把同一项要求看作是适应性或完善性维护。发人员可能把同一项要求看作是适应性或完善性维护。当存在不同意见时必须协商解决。当存在不同意见时必须协商解决。图图8.2 维护阶段的事件流维护阶段的事件流从

24、图从图8.2描绘的事件流看到，对一项改正性维护要求描绘的事件流看到，对一项改正性维护要求(图中图中“错误错误”通路通路)的处理，从估量错误的严重程度的处理，从估量错误的严重程度开始。如果是一个严重的错误开始。如果是一个严重的错误(例如，一个关键性的例如，一个关键性的系统不能正常运行系统不能正常运行)，则在系统管理员的指导下分派，则在系统管理员的指导下分派人员，并且立即开始问题分析过程。如果错误并不严人员，并且立即开始问题分析过程。如果错误并不严重，那么改正性的维护和其他要求软件开发资源的任重，那么改正性的维护和其他要求软件开发资源的任务一起统筹安排。务一起统筹安排。适应性维护和完善性维护的要求

25、沿着相同的事件流通适应性维护和完善性维护的要求沿着相同的事件流通路前进。应该确定每个维护要求的优先次序，并且安路前进。应该确定每个维护要求的优先次序，并且安排要求的工作时间，就好像它是另一个开发任务一样排要求的工作时间，就好像它是另一个开发任务一样(从所有意图和目标来看，它都属于开发工作从所有意图和目标来看，它都属于开发工作)。如果。如果一项维护要求的优先次序非常高，可能立即开始维护一项维护要求的优先次序非常高，可能立即开始维护工作。工作。不管维护类型如何，都需要进行同样的技术工作。这不管维护类型如何，都需要进行同样的技术工作。这些工作包括修改软件设计、复查、必要的代码修改、些工作包括修改软件

26、设计、复查、必要的代码修改、单元测试和集成测试单元测试和集成测试(包括使用以前的测试方案的回包括使用以前的测试方案的回归测试归测试)、验收测试和复审。不同类型的维护强调的、验收测试和复审。不同类型的维护强调的重点不同，但是基本途径是相同的。维护事件流中最重点不同，但是基本途径是相同的。维护事件流中最后一个事件是复审，它再次检验软件配置的所有成分后一个事件是复审，它再次检验软件配置的所有成分的有效性，并且保证事实上满足了维护要求表中的要的有效性，并且保证事实上满足了维护要求表中的要求。求。当然，也有并不完全符合上述事件流的维护要求。当当然，也有并不完全符合上述事件流的维护要求。当发生恶性的软件问

27、题时，就出现所谓的发生恶性的软件问题时，就出现所谓的“救火救火”维护维护要求，这种情况需要立即把资源用来解决问题。如果要求，这种情况需要立即把资源用来解决问题。如果对一个组织来说，对一个组织来说，“救火救火”是常见的过程，那么必须是常见的过程，那么必须怀疑它的管理能力和技术能力。怀疑它的管理能力和技术能力。在完成软件维护任务之后，进行处境复查常常是有好在完成软件维护任务之后，进行处境复查常常是有好处的。处的。一般说来，这种复查一般说来，这种复查试图回答下述问题：试图回答下述问题：在当前处境下设计、编码或测试的哪些方面能用不同在当前处境下设计、编码或测试的哪些方面能用不同方法进行方法进行?哪些维

28、护资源是应该有而事实上却没有的哪些维护资源是应该有而事实上却没有的?对于这项维护工作什么是主要的对于这项维护工作什么是主要的(以及次要的以及次要的)障碍障碍?要求的维护类型中有预防性维护吗要求的维护类型中有预防性维护吗?处境复查对将来维护工作的进行有重要影响，而且所处境复查对将来维护工作的进行有重要影响，而且所提供的反馈信息对有效地管理软件组织十分重要。提供的反馈信息对有效地管理软件组织十分重要。4.保存维护记录保存维护记录对于软件生命周期的所有阶段而言，以前记录保存都对于软件生命周期的所有阶段而言，以前记录保存都是不充分的，而软件维护则根本没有记录保存下来。是不充分的，而软件维护则根本没有记

29、录保存下来。由于这个原因，往往不能估价维护技术的有效性，不由于这个原因，往往不能估价维护技术的有效性，不能确定一个产品程序的能确定一个产品程序的“优良优良”程度，而且很难确定程度，而且很难确定维护的实际代价是什么。维护的实际代价是什么。保存维护记录遇到的第一个问题就是，哪些数据是值保存维护记录遇到的第一个问题就是，哪些数据是值得记录的得记录的?Swanson提出了下述内容提出了下述内容：(1)程序标识；程序标识；(2)源语句数；源语句数；(3)机器指令条数；机器指令条数；(4)使用的程序设计使用的程序设计语言；语言；(5)程序安装的日期；程序安装的日期；(6)自从安装以来程序运自从安装以来程序

30、运行的次数；行的次数；(7)自从安装以来程序失效的次数；自从安装以来程序失效的次数；(8)程程序变动的层次和标识；序变动的层次和标识；(9)因程序变动而增加的源语因程序变动而增加的源语句数；句数；(10)因程序变动而删除的源语句数；因程序变动而删除的源语句数；(11)每个每个改动耗费的人时数；改动耗费的人时数；(12)程序改动的日期；程序改动的日期；(13)软件软件工程师的名字；工程师的名字；(14)维护要求表的标识；维护要求表的标识；(15)维护类维护类型；型；(16)维护开始和完成的日期；维护开始和完成的日期；(17)累计用于维护累计用于维护的人时数；的人时数；(18)与完成的维护相联系的

31、纯效益。与完成的维护相联系的纯效益。应该为每项维护工作都收集上述数据。可以利用这些应该为每项维护工作都收集上述数据。可以利用这些数据构成一个维护数据库的基础，并且像下面介绍的数据构成一个维护数据库的基础，并且像下面介绍的那样对它们进行评价。那样对它们进行评价。5.评价维护活动评价维护活动缺乏有效的数据就无法评价维护活动。如果已经开始缺乏有效的数据就无法评价维护活动。如果已经开始保存维护记录了，则可以对维护工作做一些定量度量。保存维护记录了，则可以对维护工作做一些定量度量。至少可以从下述至少可以从下述7个方面度量维护工作：个方面度量维护工作：(1)每次程序运行平均失效的次数；每次程序运行平均失效

32、的次数；(2)用于每一类维护活动的总人时数；用于每一类维护活动的总人时数；(3)平均每个程序、每种语言、每种维护类型所做的平均每个程序、每种语言、每种维护类型所做的程序变动数；程序变动数；(4)维护过程中增加或删除一个源语句平均花费的人维护过程中增加或删除一个源语句平均花费的人时数；时数；(5)维护每种语言平均花费的人时数；维护每种语言平均花费的人时数；(6)一张维护要求表的平均周转时间；一张维护要求表的平均周转时间；(7)不同维护类型所占的百分比。不同维护类型所占的百分比。根据对维护工作定量度量的结果，可以做出关于开发根据对维护工作定量度量的结果，可以做出关于开发技术、语言选择、维护工作量规

33、划、资源分配及其他技术、语言选择、维护工作量规划、资源分配及其他许多方面的决定，而且可以利用这样的数据去分析评许多方面的决定，而且可以利用这样的数据去分析评价维护任务。价维护任务。可以把软件的可维护性定性地定义为：可以把软件的可维护性定性地定义为：维护人员理维护人员理解、改正、改动或改进这个软件的难易程度。在前面解、改正、改动或改进这个软件的难易程度。在前面的章节中曾经多次强调，提高可维护性是支配软件工的章节中曾经多次强调，提高可维护性是支配软件工程方法学所有步骤的关键目标。程方法学所有步骤的关键目标。8.4 软件的可维护性软件的可维护性维护就是在软件交付使用后进行的修改，修改之前必维护就是在

34、软件交付使用后进行的修改，修改之前必须理解待修改的对象，修改之后应该进行必要的测试，须理解待修改的对象，修改之后应该进行必要的测试，以保证所做的修改是正确的。如果是改正性维护，还以保证所做的修改是正确的。如果是改正性维护，还必须预先进行调试以确定错误的具体位置。因此，决必须预先进行调试以确定错误的具体位置。因此，决定软件可维护性的因素主要有下述定软件可维护性的因素主要有下述5个：个：8.4.1 决定软件可维护性的因素决定软件可维护性的因素1.可理解性可理解性软件可理解性表现为软件可理解性表现为外来读者外来读者理解软件的结构、功能、理解软件的结构、功能、接口和内部处理过程的难易程度。模块化（模块

35、结构接口和内部处理过程的难易程度。模块化（模块结构良好，高内聚，松耦合）、详细的设计文档、结构化良好，高内聚，松耦合）、详细的设计文档、结构化设计、程序内部的文档和良好的高级程序设计语言等设计、程序内部的文档和良好的高级程序设计语言等等，都对提高软件的可理解性有重要贡献。等，都对提高软件的可理解性有重要贡献。2.可测试性可测试性诊断和测试的容易程度诊断和测试的容易程度取决于软件容易理解的程度。取决于软件容易理解的程度。良好的文档对诊断和测试是至关重要的，此外，软件良好的文档对诊断和测试是至关重要的，此外，软件结构、可用的测试工具和调试工具，以及以前设计的结构、可用的测试工具和调试工具，以及以前

36、设计的测试过程也都是非常重要的。维护人员应该能够得到测试过程也都是非常重要的。维护人员应该能够得到在开发阶段用过的测试方案，以便进行回归测试。在在开发阶段用过的测试方案，以便进行回归测试。在设计阶段应该尽力把软件设计成容易测试和容易诊断设计阶段应该尽力把软件设计成容易测试和容易诊断的。的。对于程序模块来说，可以用程序复杂度来度量它的可对于程序模块来说，可以用程序复杂度来度量它的可测试性。测试性。模块的环形复杂度越大，可执行的路径就越模块的环形复杂度越大，可执行的路径就越多，因此，全面测试它的难度就越高。多，因此，全面测试它的难度就越高。3.可修改性可修改性软件容易修改的程度软件容易修改的程度和

37、本书第和本书第5章讲过的设计原理和章讲过的设计原理和启发规则直接有关。耦合、内聚、信息隐藏、局部化、启发规则直接有关。耦合、内聚、信息隐藏、局部化、控制域与作用域的关系等等，都影响软件的可修改性。控制域与作用域的关系等等，都影响软件的可修改性。4.可移植性可移植性软件可移植性指的是，软件可移植性指的是，把程序从一种计算环境（硬件把程序从一种计算环境（硬件配置和操作系统）转移到另一种计算环境的难易程度。配置和操作系统）转移到另一种计算环境的难易程度。把与硬件、操作系统以及其他外部设备有关的程序代把与硬件、操作系统以及其他外部设备有关的程序代码集中放到特定的程序模块中，可以把因环境变化而码集中放到

38、特定的程序模块中，可以把因环境变化而必须修改的程序局限在少数程序模块中，从而降低修必须修改的程序局限在少数程序模块中，从而降低修改的难度。改的难度。5.可重用性可重用性所谓重用（所谓重用（reuse）是指同一事物不做修改或稍加改）是指同一事物不做修改或稍加改动就在不同环境中多次重复使用。动就在不同环境中多次重复使用。大量使用可重用的大量使用可重用的软件构件来开发软件，可以从下述两个方面提高软件软件构件来开发软件，可以从下述两个方面提高软件的可维护性：的可维护性：(1)通常，可重用的软件构件在开发时经过很严格的通常，可重用的软件构件在开发时经过很严格的测试，可靠性比较高，且在每次重用过程中都会发

39、现测试，可靠性比较高，且在每次重用过程中都会发现并清除一些错误，随着时间推移，这样的构件将变成并清除一些错误，随着时间推移，这样的构件将变成实质上无错误的。因此，实质上无错误的。因此，软件中使用的可重用构件越软件中使用的可重用构件越多，软件的可靠性越高，改正性维护需求越少。多，软件的可靠性越高，改正性维护需求越少。（2）很容易修改可重用的软件构件使之再次应用在很容易修改可重用的软件构件使之再次应用在新环境中，因此，软件中使用的可重用构件越多，适新环境中，因此，软件中使用的可重用构件越多，适应性和完善性维护也就越容易。应性和完善性维护也就越容易。文档是影响软件可维护性的决定因素。文档是影响软件可

40、维护性的决定因素。由于长期使用由于长期使用的大型软件系统在使用过程中必然会经受多次修改，的大型软件系统在使用过程中必然会经受多次修改，所以文档比程序代码更重要。所以文档比程序代码更重要。软件系统的文档可以分为用户文档和系统文档两类。软件系统的文档可以分为用户文档和系统文档两类。用户文档主要描述系统功能和使用方法，并不关心这用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；系统文档描述系统设计、实现些功能是怎样实现的；系统文档描述系统设计、实现和测试等各方面的内容。和测试等各方面的内容。总的说来，总的说来，软件文档应该满足下述要求：软件文档应该满足下述要求：8.4.2 文档文档(

41、1)必须描述如何使用这个系统，没有这种描述时即必须描述如何使用这个系统，没有这种描述时即使是最简单的系统也无法使用；使是最简单的系统也无法使用；(2)必须描述怎样安装和管理这个系统；必须描述怎样安装和管理这个系统；(3)必须描述系统需求和设计；必须描述系统需求和设计；(4)必须描述系统的实现和测试，以便使系统成为可必须描述系统的实现和测试，以便使系统成为可维护的。维护的。下面分别讨论用户文档和系统文档。下面分别讨论用户文档和系统文档。1.用户文档用户文档用户文档是用户了解系统的第一步，它应该能使用户用户文档是用户了解系统的第一步，它应该能使用户获得对系统的准确的初步印象。文档的结构方式应该获得

42、对系统的准确的初步印象。文档的结构方式应该使用户能够方便地根据需要阅读有关的内容。使用户能够方便地根据需要阅读有关的内容。用户文档至少应该包括下述用户文档至少应该包括下述5方面的内容：方面的内容：(1)功能描述，说明系统能做什么；功能描述，说明系统能做什么；(2)安装文档，说明怎样安装这个系统以及怎样使系安装文档，说明怎样安装这个系统以及怎样使系统适应特定的硬件配置；统适应特定的硬件配置；(3)使用手册，简要说明如何着手使用这个系统使用手册，简要说明如何着手使用这个系统(应该应该通过丰富例子说明怎样使用常用的系统功能，还应该通过丰富例子说明怎样使用常用的系统功能，还应该说明用户操作错误时怎样恢

43、复和重新启动说明用户操作错误时怎样恢复和重新启动)；(4)参考手册，详尽描述用户可以使用的所有系统设参考手册，详尽描述用户可以使用的所有系统设施以及它们的使用方法，还应该解释系统可能产生的施以及它们的使用方法，还应该解释系统可能产生的各种出错信息的含义各种出错信息的含义(对参考手册最主要的要求是完对参考手册最主要的要求是完整，因此通常使用形式化的描述技术整，因此通常使用形式化的描述技术)；(5)操作员指南操作员指南(如果需要有系统操作员的话如果需要有系统操作员的话)，说明，说明操作员应该如何处理使用中出现的各种情况。操作员应该如何处理使用中出现的各种情况。上述内容可以分别作为独立的文档，也可以

44、作为用户上述内容可以分别作为独立的文档，也可以作为用户手册的不同分册，具体做法应该由系统规模决定。手册的不同分册，具体做法应该由系统规模决定。2.系统文档系统文档所谓系统文档指从问题定义、需求说明到验收测试计所谓系统文档指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计、划这样一系列和系统实现有关的文档。描述系统设计、实现和测试的文档对于理解程序和维护程序来说是极实现和测试的文档对于理解程序和维护程序来说是极端重要的。和用户文档类似，系统文档的结构也应该端重要的。和用户文档类似，系统文档的结构也应该能把读者从对系统概貌的了解，引导到对系统每个方能把读者从对系统概貌

45、的了解，引导到对系统每个方面每个特点的更形式化更具体的认识。本书前面各章面每个特点的更形式化更具体的认识。本书前面各章已经较详细地介绍了已经较详细地介绍了各个阶段应该产生的文档各个阶段应该产生的文档，此处，此处不再重复。不再重复。可维护性是所有软件都应该具备的基本特点，必须在可维护性是所有软件都应该具备的基本特点，必须在开发阶段保证软件具有节中提到的那些可维护因素。开发阶段保证软件具有节中提到的那些可维护因素。在软件工程过程的每一个阶段都应该考虑并努力提高在软件工程过程的每一个阶段都应该考虑并努力提高软件的可维护性，软件的可维护性，在每个阶段结束前的技术审查和管在每个阶段结束前的技术审查和管理

46、复审中，应该着重对可维护性进行复审。理复审中，应该着重对可维护性进行复审。在需求分析阶段在需求分析阶段的复审过程中，应该对将来要改进的的复审过程中，应该对将来要改进的部分和可能会修改的部分加以注意并指明；应该讨论部分和可能会修改的部分加以注意并指明；应该讨论软件的可移植性问题，并且考虑可能影响软件维护的软件的可移植性问题，并且考虑可能影响软件维护的系统界面。系统界面。8.4.3 可维护性复审可维护性复审在正式的和非正式的在正式的和非正式的设计设计复审期间，应该从容易修改、复审期间，应该从容易修改、模块化和功能独立的目标出发，评价软件的结构和过模块化和功能独立的目标出发，评价软件的结构和过程；设

47、计中应该对将来可能修改的部分预作准备。程；设计中应该对将来可能修改的部分预作准备。代码代码复审应该强调编码风格和内部说明文档这两个影复审应该强调编码风格和内部说明文档这两个影响可维护性的因素。响可维护性的因素。另外另外，在设计和编码过程中应该尽量使用可重用的软，在设计和编码过程中应该尽量使用可重用的软件构件，如果需要开发新的构件，也应该注意提高构件构件，如果需要开发新的构件，也应该注意提高构件的可重用性。件的可重用性。每个测试步骤都可以暗示在软件正式交付使用前，程每个测试步骤都可以暗示在软件正式交付使用前，程序中可能需要做预防性维护的部分。在序中可能需要做预防性维护的部分。在测试测试结束时进结

48、束时进行最正式的可维护性复审，这个复审称为配置复审。行最正式的可维护性复审，这个复审称为配置复审。配置复审的目的是保证软件配置的所有成分是配置复审的目的是保证软件配置的所有成分是完整的、完整的、一致的和可理解的一致的和可理解的，而且为了便于修改和管理已经编，而且为了便于修改和管理已经编目归档了。目归档了。在完成了每项维护工作之后，都应该对软件维护本身在完成了每项维护工作之后，都应该对软件维护本身进行仔细认真的复审。进行仔细认真的复审。维护应该针对整个软件配置，不应该只修改源程序代维护应该针对整个软件配置，不应该只修改源程序代码。当对源程序代码的修改没有反映在设计文档或用码。当对源程序代码的修改

49、没有反映在设计文档或用户手册中时，就会产生严重的后果。户手册中时，就会产生严重的后果。每当每当对数据、软件结构、模块过程或任何其他有关的对数据、软件结构、模块过程或任何其他有关的软件特点做了软件特点做了改动改动时，必须立即修改相应的技术文档。时，必须立即修改相应的技术文档。不能准确反映软件当前状态的设计文档可能比完全没不能准确反映软件当前状态的设计文档可能比完全没有文档更坏。在以后的维护工作中很可能因文档不完有文档更坏。在以后的维护工作中很可能因文档不完全符合实际而不能正确理解软件，从而在维护中引入全符合实际而不能正确理解软件，从而在维护中引入过多的错误。过多的错误。用户通常根据描述软件特点和

50、使用方法的用户文档来用户通常根据描述软件特点和使用方法的用户文档来使用、评价软件。如果对软件的可执行部分的修改没使用、评价软件。如果对软件的可执行部分的修改没有及时反映在用户文档中，则必然会使用户因为受挫有及时反映在用户文档中，则必然会使用户因为受挫折而产生不满。折而产生不满。如果在软件再次交付使用之前，对软件配置进行严格如果在软件再次交付使用之前，对软件配置进行严格的复审，则可大大减少文档的问题。事实上，某些维的复审，则可大大减少文档的问题。事实上，某些维护要求可能并不需要修改软件设计或源程序代码，只护要求可能并不需要修改软件设计或源程序代码，只是表明用户文档不清楚或不准确，因此只需要对文档