《实用软件工程》PPT课件.ppt

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

1、在在软软件件的的开开发发工工作作已已完完成成并并把把软软件件产产品品交交付付给给用用户户使使用用之之后后，就就进进入入了了软软件件维维护护阶阶段段。这这个个阶阶段段的的工工作作目目标标是是保保证证软软件件在在一一个个相相当当长长的的时时期期内内能能够够正正常常运运行行，因因此对软件的维护就成为必不可少的了。此对软件的维护就成为必不可少的了。软软件件维维护护需需要要的的工工作作量量非非常常大大。平平均均说说来来，大大型型软软件件的的维维护护成成本本高高达达开开发发成成本本的的四四倍倍左左右右。目目前前国国外外许许多多软软件件开开发发组组织织把把60%60%以以上上的的人人力力用用于于维维护护已已

2、有有的的软软件件，而而且且随随着着软软件件数数量量增增多多和和使使用用寿寿命命延延长长，这这个个百百分分比比还还在在持持续续上上升升。将将来来维维护护工工作作甚甚至至可可能能会会束束缚缚住住软软件件开开发发组组织的手脚，使他们没有余力开发新的软件。织的手脚，使他们没有余力开发新的软件。6.1 软件维护的内容及特点软件维护的内容及特点6.1.1 软件维护的内容软件维护的内容 所所谓谓软软件件维维护护就就是是在在软软件件已已经经交交付付使使用用之之后后，为为了改正错误或满足新的需要而修改软件的过程了改正错误或满足新的需要而修改软件的过程。我我们们可可以以通通过过描描述述软软件件交交付付使使用用后后

3、可可能能进进行行的的下下述四项活动述四项活动，具体地定义软件维护具体地定义软件维护。1.改正性维护改正性维护通常，在软件开发过程中所进行的测试都是不完通常，在软件开发过程中所进行的测试都是不完全、不彻底的，软件中必然会有一些潜伏的错误被带到全、不彻底的，软件中必然会有一些潜伏的错误被带到运行阶段来。用户常常将把他们遇到的问题报告给软件运行阶段来。用户常常将把他们遇到的问题报告给软件维护人员，要求解决。维护人员，要求解决。我们把诊断和改正软件错误的过程称为我们把诊断和改正软件错误的过程称为改正性维护改正性维护。例如，在软件交付用户使用之后，解决在开发时没有测例如，在软件交付用户使用之后，解决在开

4、发时没有测试所有可能的执行通路而带来的问题；解决程序中遗漏试所有可能的执行通路而带来的问题；解决程序中遗漏对文件中最后一个记录的处理的错误等。对文件中最后一个记录的处理的错误等。2.适应性维护适应性维护 计计算算机机科科学学技技术术领领域域的的各各个个方方面面都都在在迅迅速速进进步步，大大约约每每过过3636个个月月就就有有新新一一代代的的硬硬件件宣宣告告出出现现；另另一一方方面面，应应用用软软件件的的使使用用寿寿命命却却很很容容易易超超过过十十年年，远远远远长长于于最最初初开开发发这这个个软软件件时时的的运运行行环环境境的的寿寿命命。因因此此，适适应应性性维维护护就就是是为为了了和和变变化化

5、了了的的环环境境适适当当地地配配合合而而进进行行的的修修改改软软件件的的活活动动，是是既必要又经常的维护活动。既必要又经常的维护活动。例例如如，适适应应性性维维护护可可以以是是修修改改原原在在DOSDOS操操作作系系统统中中运运行行的的程程序序，使使之之能能在在WindowsWindows操操作作系系统统中中运运行行；修修改改两两个个程程序序，使使它它们们能能够够使使用用相相同同的的记记录录结结构构；修修改改程程序序，使使它它适适用用于于另外一种终端设备。另外一种终端设备。3.完善性维护完善性维护在在使使用用软软件件的的过过程程中中，用用户户往往往往提提出出增增加加新新功功能能或或改改变变某某

6、些些已已有有功功能能的的要要求求，还还可可能能提提出出提提高高程程序序性性能能的的要要求求。为为了了满满足足这这类类要要求求而而修修改改软软件件的的活活动动，称称为为完完善善性性维维护护。例例如如，在在储储蓄蓄系系统统交交付付银银行行使使用用之之后后，增增加加扣扣除除利利息息税税的的功功能能；缩缩短短系系统统的的响响应应时时间间，使使之之达达到到新新的的要要求求；改改变变现现有有程程序序输输出出数数据据的的格格式式，以以方方便便用用户户；在在正正在在运运行行的的软件中增加联机求助功能等，都是完善性维护。软件中增加联机求助功能等，都是完善性维护。4.预防性维护预防性维护当当为为了了提提高高未未来

7、来的的可可维维护护性性或或可可靠靠性性，或或为为了了给给未未来来的的改改进进工工作作奠奠定定更更好好的的基基础础而而修修改改软软件件时时，就就出出现现了了第第四四类类维维护护活活动动，这这类类维维护护活活动动称称为为预预防防性性维维护护。通通常常，把把预预防防性性维维护护定定义义为为：“把把今今天天的的方方法法学学应应用用于于昨昨天天的的系系统统以以满满足足明明天天的的需需要要”。也也就就是是说说，预预防防性性维维护护就就是是采采用用先先进进的的软软件件工工程程方方法法对对需需要要维维护护的的软软件件或或软软件件中中的的某某一一部部分分，主主动动地地进进行行重重新设计、编码和测试。新设计、编码

8、和测试。在维护阶段的最初一二年，在维护阶段的最初一二年，改正性维护改正性维护的工作量往往比的工作量往往比较大。随着在软件运行过程中错误发现率迅速降低并趋于稳较大。随着在软件运行过程中错误发现率迅速降低并趋于稳定，就进入了正常使用期间。但是，由于用户经常提出改造定，就进入了正常使用期间。但是，由于用户经常提出改造软件的要求，软件的要求，适应性维护和完善性维护适应性维护和完善性维护的工作量逐渐增加，的工作量逐渐增加，而且在这种维护过程中往往又会引入新的错误，从而进一步而且在这种维护过程中往往又会引入新的错误，从而进一步加大了维护的工作量。加大了维护的工作量。从上述关于软件维护的定义不难看出，软件维

9、护绝不仅从上述关于软件维护的定义不难看出，软件维护绝不仅限于纠正使用中发现的错误，事实上在全部维护活动中一半限于纠正使用中发现的错误，事实上在全部维护活动中一半以上是完善性维护。以上是完善性维护。国外的统计数字表明：国外的统计数字表明：完善性维护占全部维护活动的完善性维护占全部维护活动的50%66%改正性维护占改正性维护占17%21%，适应性维护占适应性维护占18%25%，其他维护活动只占其他维护活动只占4%左右。左右。软件维护策略软件维护策略针对上一小节所述的三种典型的维护活动，JamesMartin等等人人提提出出了了一一些些可可以以减减少少维维护护成成本本的的策策略略。下下面面学习主要的

10、软件维护策略。学习主要的软件维护策略。1.降低改正性维护成本的策略降低改正性维护成本的策略 显然，软件中包含的错误越少，改正性维护的成本显然，软件中包含的错误越少，改正性维护的成本也就越低，但是，要生成也就越低，但是，要生成100%100%可靠的软件通常成本太高，可靠的软件通常成本太高，并不一定合算。然而通过使用先进技术仍然可以大大提并不一定合算。然而通过使用先进技术仍然可以大大提高软件的可靠性，从而减少改正性维护的需求。高软件的可靠性，从而减少改正性维护的需求。2.降低适应性维护成本的策略降低适应性维护成本的策略这类维护是必然要进行的，但是要采取适当的策略。（1 1）在进行配置管理时，把硬件

11、、操作系统和其他相关的）在进行配置管理时，把硬件、操作系统和其他相关的环境因素的可能变化考虑在内，可以减少某些适应性维护的环境因素的可能变化考虑在内，可以减少某些适应性维护的工作量；工作量；（2 2）把与硬件、操作系统及其他外围设备有关的代码放到）把与硬件、操作系统及其他外围设备有关的代码放到特定的程序模块中，可以把因环境变化而必须修改的程序代特定的程序模块中，可以把因环境变化而必须修改的程序代码局限于某些特定的程序模块内；码局限于某些特定的程序模块内；（3 3）使用内部程序列表、外部文件及例行处理程序包，可）使用内部程序列表、外部文件及例行处理程序包，可以为维护时修改程序提供方便。以为维护时

12、修改程序提供方便。3.降低完善性维护成本的策略降低完善性维护成本的策略 上述的减少前两类维护成本的策略，通常也能降低上述的减少前两类维护成本的策略，通常也能降低完善性维护的成本。特别是数据库管理系统、程序自动完善性维护的成本。特别是数据库管理系统、程序自动生成系统、软件开发环境、第四代语言和应用软件包，生成系统、软件开发环境、第四代语言和应用软件包，可明显减少维护工作量。可明显减少维护工作量。此外，在需求分析过程中准确地预测用户将来可能此外，在需求分析过程中准确地预测用户将来可能提出的需求，并且在设计时为将来可能提出的需求预先提出的需求，并且在设计时为将来可能提出的需求预先做准备，显然是降低完

13、善性维护成本的有力措施。做准备，显然是降低完善性维护成本的有力措施。在实际开发软件之前，建立软件的原型并让用户试在实际开发软件之前，建立软件的原型并让用户试用，以进一步完善他们对软件的功能需求，也能显著减用，以进一步完善他们对软件的功能需求，也能显著减少软件交付使用之后的完善性维护需求。少软件交付使用之后的完善性维护需求。6.1.2 软件维护的软件维护的的特点的特点图描绘了面对一项维护要求时，不同的软件配置所导致的不同工作流程。图结构化维护与非结构化维护的对比非结构化维护结构化维护6.1.2.1结构化维护与非结构化维护差别悬殊结构化维护与非结构化维护差别悬殊 如如果果软软件件配配置置的的惟惟一

14、一成成分分是是程程序序代代码码，那那么么维维护护活活动动从从艰艰苦苦地地评评价价程程序序代代码码开开始始，而而且且常常常常由由于于程程序序内内部部文文档档不不足足而而使使评评价价更更困困难难（诸诸如如软软件件结结构构、全全程程数数据据结结构构、系系统统接接口口、性性能能或或设设计计约约束束等等微微妙妙的的特特点点是是难难于于搞搞清清的的，而而且且常常常常误误解解了了这这一一类类特特点点）。最最终终对对程程序序代代码码所所做做的的改改动动的后果是难于估量的。的后果是难于估量的。因因为为没没有有测测试试方方面面的的文文档档，所所以以不不可可能能进进行行回回归归测测试试。这这就就是是非非结结构构化化

15、维维护护，这这种种维维护护方方式式是是没没有有使使用用良良好好定定义义的的方方法法学学开开发发出出来来的的软软件件的的必必然然结结果果-并并正正在在为为此此而而付付出出代价（浪费精力和受挫折）。代价（浪费精力和受挫折）。非结构化维护非结构化维护(上图右侧)如如果果有有一一个个完完整整的的软软件件配配置置存存在在，那那么么维维护护工工作作从从评评价价设设计计文文档档开开始始，确确定定软软件件重重要要的的结结构构特特点点、性性能能特特点点以以及及接接口口特特点点；估估量量要要求求的的改改动动将将带带来来的的影影响响，并并且且计计划划实实施施途途径径。然然后后首首先先修修改改设设计计并并且且对对所所

16、做做的的修修改改进进行行仔仔细细复复查查。接接下下来来编编写写相相应应的的源源程程序序代代码码；使使用用在在测测试试说说明明书书中中包包含含的的信信息息进进行行回回归归测测试试；最最后后，把把修修改改后后的的软软件件再再次次交交付使用。付使用。上上面面描描述述的的事事件件构构成成结结构构化化维维护护，它它是是在在软软件件开开发发的的早早期期应应用用软软件件工工程程方方法法学学的的结结果果。（它它确确实实能能减减少少精精力力的的浪费并且能提高维护的总体质量。）浪费并且能提高维护的总体质量。）6.1.2.2维护的代价高昂维护的代价高昂在在过过去去的的几几十十年年中中，软软件件维维护护的的费费用用稳

17、稳步步上上升升。19701970年年用用于于维维护护已已有有软软件件的的费费用用只只占占软软件件总总预预算算的的35%35%40%40%，19801980年年上上升升为为40%40%60%60%，19901990年上升为年上升为70%70%80%80%。维维护护费费用用只只不不过过是是软软件件维维护护的的最最明明显显的的代代价价，其其他他一一些些现现在在还还不不明明显显的的代代价价将将来来可可能能更更为为人人们们所所关关注注。因因为为可可用用的的资资源源必必须须供供维维护护任任务务使使用用，以以致致耽耽误误甚甚至至丧丧失失了了开开发发新新软软件件的的良良机机，这这是是软软件件维维护护的的一一个

18、个无无形形的代价的代价。其他无形的代价还有：其他无形的代价还有：当看来合理的有关改错或修改的要求不能及时满足时将引起用户不满；由于维护时的改动，在软件中引入了潜伏的故障，从而降低了软件的质量；当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱。软件维护的最后一个代价是生产率的大幅度下降，这软件维护的最后一个代价是生产率的大幅度下降，这种情况在维护旧程序时常常遇到。例如，据种情况在维护旧程序时常常遇到。例如，据GauslerGausler在在19761976年的报道，美国空军的飞行控制软件每条指令的开发成本年的报道，美国空军的飞行控制软件每条指令的开发成本是是7575美元，然而维护成本

19、大约是每条指令美元，然而维护成本大约是每条指令40004000美元，也就美元，也就是说，生产率下降了是说，生产率下降了5050倍以上。倍以上。用用用用于于于于维维维维护护护护工工工工作作作作的的的的劳劳劳劳动动动动（活活活活动动动动）可可可可以以以以分分分分成成成成生生生生产产产产性性性性活活活活动动动动（例例如如，分分析析评评价价，修修改改设设计计和和编编写写程程序序代代码码等等）和和和和非非非非生生生生产产产产性性性性活活活活动动动动（例例如如，理理解解程程序序代代码码的的功功能能，解解释释数数据据结结构构、接接口口特点和性能限度等）。特点和性能限度等）。下述公式给出下述公式给出维护工作量

20、维护工作量的一个模型的一个模型:其中：其中：M是维护用的总工作量 P是生产性工作量 K是经验常数 c是复杂程度（非结构化设计和缺少文档都会增加软件的复杂程度）d是维护人员对软件的熟悉程度。上面的模型表明，如果软件的开发途径不好（即，没有使用软件工程方法学），而且原来的开发人员不能参加维护工作，那么维护工作量（和费用）将指数地增加。MPKexp（cd）6.1.2.3维护的困难性维护的困难性与软件维护有关的绝大多数困难，都可归因于软件定义和软件开发的方法有缺点。在软件生命周期的头两个时期没有严格而又科学的管理和规划，几乎必然会导致在最后阶段出现问题。下面列出和软件维护有关的部分问题下面列出和软件维

21、护有关的部分问题：读懂别人写的程序通常非常困难。而且困难程度随着软件配置成分的减少而迅速增加。如果仅有程序代码没有说明文档，则会出现严重的问题。需要维护的软件往往没有合格一致的文档，或者文档资料显著不足。认识到软件必须有文档仅仅是第一步，容易理解并且和程序代码完全一致的文档才真正有价值。当要求对软件进行维护时，不能指望由开发人员给我们仔细说明软件。由于维护阶段持续的时间很长，因此，当需要解释软件时，往往原来写程序的人已不在现场了。绝大多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理的设计方法学，否则修改软件既困难又容易发生差错。软件维护不是一项吸引人的工作。形成这种观念很大程度上是

22、因为维护工作经常遭受挫折。上述种种困难存在于现有的没采用软件工程思想开发上述种种困难存在于现有的没采用软件工程思想开发出来的软件中。出来的软件中。不应该把一种科学的方法学看做万应灵药，不应该把一种科学的方法学看做万应灵药，但是，软件工程至少部分地解决了与维护有关的每一个问但是，软件工程至少部分地解决了与维护有关的每一个问题。题。6.2软件的可维护性软件的可维护性6.2.1软件的可维护性软件的可维护性-指软件能够被维护人员理解、改正、适应和完指软件能够被维护人员理解、改正、适应和完善以适应新的环境的难易程度。善以适应新的环境的难易程度。决定软件可维护性的因素决定软件可维护性的因素维护就是在软件交

23、付使用后进行的修改，修改之前必维护就是在软件交付使用后进行的修改，修改之前必须理解修改的对象，修改之后应该进行必要的测试，以保须理解修改的对象，修改之后应该进行必要的测试，以保证所做的修改是正确的。如果是改正性维护，还必须预先证所做的修改是正确的。如果是改正性维护，还必须预先进行调试以确定错误。因此，进行调试以确定错误。因此，影响软件可维护性的因素主影响软件可维护性的因素主要有下述七个：要有下述七个：1.可理解性可理解性2.可测试性可测试性3.可修改性可修改性4.可靠性可靠性5.可移植性可移植性6.可重用性可重用性7.效率效率6.2.2文档文档文文档档是是影影响响软软件件可可维维护护性性的的决

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

25、系统，没有这种描述即使是最）必须描述如何使用这个系统，没有这种描述即使是最简单的系统也无法使用；简单的系统也无法使用；（2 2）必须描述怎样安装和管理这个系统；）必须描述怎样安装和管理这个系统；（3 3）必须描述系统需求和设计；）必须描述系统需求和设计；（4 4）必须描述系统的实现和测试，以便使系统成为可维护）必须描述系统的实现和测试，以便使系统成为可维护的。的。6.2.3 提高软件可维护性的方法提高软件可维护性的方法 从以下五方面解决：从以下五方面解决：1建立明确的软件质量标准建立明确的软件质量标准2利用先进的软件技术和工具利用先进的软件技术和工具3建立明确的质量保证制度建立明确的质量保证制

26、度4选择可维护的程序设计语言选择可维护的程序设计语言5改进软件的文档改进软件的文档。6.2.4可维护性复审可维护性复审 可维护性是所有软件都应该具备的基本特点。在软件工可维护性是所有软件都应该具备的基本特点。在软件工程过程的每一个阶段都应该考虑并努力提高软件的可维护性，程过程的每一个阶段都应该考虑并努力提高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对可在每个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。维护性进行复审。6.3软件维护实施过程软件维护实施过程首先必须建立一个维护组织，随后必须确定报告和评价的过程，而且必须为每个维护要求规定一个标准化的事件序列

27、。此外，还应该建立一个适用于维护活动的记录保管过程，并且规定复审标准。6.3.1维护组织维护组织虽虽然然通通常常并并不不需需要要建建立立正正式式的的维维护护组组织织，但但是是，即即使使对对于于一一个个小小的的软软件件开开发发团团体体而而言言，非非正正式式地地委委托托责责任任也也是是绝绝对对必必要要的的。维维护护机机构构成成员员一一般般包包括括：配配置置管管理理员员、维维护护控控制员、系统管理员、一般维护工作人员。制员、系统管理员、一般维护工作人员。每每个个维维护护要要求求都都通通过过维维护护管管理理员员转转交交给给相相应应的的系系统统管管理理员去评价员去评价，见下页图示。，见下页图示。维护机构

28、维护机构 提示提示：在维护在维护活动开始之前就活动开始之前就明确维护责任是明确维护责任是十分必要的，这十分必要的，这样做可以大大减样做可以大大减少维护过程中可少维护过程中可能出现的混乱能出现的混乱。系统管理员系统管理员是被指定去熟悉一小部分产品程序的技术人员是被指定去熟悉一小部分产品程序的技术人员。系统管理员对维护任务做出评价之后，由变化授权人决定应该进行的活动。图描绘了上述组织方式。图6.3.2维护报告维护报告应应该该用用标标准准化化的的格格式式表表达达所所有有软软件件维维护护要要求求。软软件件维维护护人人员员通通常常给给用用户户提提供供空空白白的的维维护护要要求求表表有有时时称称为为软软件

29、件问问题题报报告告表表，这这个个表表格格由由要要求求一一项项维维护护活活动动的的用用户填写。户填写。如如果果遇遇到到了了一一个个错错误误，那那么么必必须须完完整整描描述述导导致致出出现现错错误误的的环环境境（包包括括输输入入数数据据，全全部部输输出出数数据据，以以及及其其他他有有关关信信息息）。对对于于适适应应性性或或完完善善性性的的维维护护要要求求，应应该该提提出出一一个个简简短短的的需需求求说说明明书书。如如前前所所述述，由由维维护护管管理理员员和和系统管理员评价用户提交的维护要求表。系统管理员评价用户提交的维护要求表。维护要求表维护要求表是一个外部产生的文件，它是计划维护活是一个外部产生

30、的文件，它是计划维护活动的基础动的基础。软件组织内部应该制定出一个软件修改报告软件修改报告，它给出下述信息：它给出下述信息：（1）满足维护要求表中提出的要求所需要的工作量；（2）维护要求的性质；（3）这项要求的优先次序；（4）与修改有关的事后数据。在拟定进一步的维护计划之前，把软件修改报告提交在拟定进一步的维护计划之前，把软件修改报告提交给变化授权人审查批准。给变化授权人审查批准。6.3.3维护的事件流维护的事件流 图描绘了由一项维护要求而引出的一串事件。图描绘了由一项维护要求而引出的一串事件。1 1、首先应该确定要求进行的首先应该确定要求进行的维护的类型维护的类型。用户常常把一项要求看作是为

31、了改正软件的错误（即改正性维护）。用户常常把一项要求看作是为了改正软件的错误（即改正性维护），而开发人员可能把同一项要求看作是适应性或完善性维护。，而开发人员可能把同一项要求看作是适应性或完善性维护。当存在不同意见当存在不同意见时必须协商解决。时必须协商解决。从图描绘的事件流看到：从图描绘的事件流看到：2 2、对对改改（校校）正正性性维维护护要要求求的的处处理理，从从估估量量错错误误的的严严重重程程度度开开始始。如果是一个严重的错误（例如，一个关键性的系统不能正常运行），则在系统管理员的指导下分派人员，并且立即开始问题分析过程。如果错误并不严重，那么改正性的维护和其他要求软件开发资源的任务一起

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

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

34、，就就出出现现所所谓谓的的“救救火火”维维护护要要求求，这这种种情情况况需需要要立立即即把把资资源源用用来来解解决决问问题题。（如如果果对对一一个个组组织织来来说说，“救救火火”是是常常见见的的过过程程，那那么么就就必必须须怀怀疑疑它它的的管管理理能能力和技术能力力和技术能力。）。）在完成软件维护任务之后，进行处境复查常常是有好处进行处境复查常常是有好处的的。一般说来，这种复查试图回答下述问题：在当前处境下设计、编码或测试的哪些方面能用不同方法进行?哪些维护资源是应该有而事实上却没有的?对于这项维护工作什么是主要的、次要的障碍是什么?要求的维护类型中有预防性维护吗?处境复查对将来维护工作的进行

35、有重要影响，而且所提供的反馈信息对有效地管理软件组织十分重要。6.3.4保存维护记录保存维护记录 对对于于软软件件生生命命周周期期的的所所有有阶阶段段而而言言，以以前前记记录录保保存存都都是是不不充充分分的的，而而软软件件维维护护则则根根本本没没有有记记录录保保存存下下来来。由由于于这这个个原原因因，我我们们往往往往不不能能估估价价维维护护技技术术的的有有效效性性，不不能能确确定定一一个个产产品品程程序序的的“优优良良”程程度度，而而且且很很难难确确定定维维护护的的实实际际代价是什么。代价是什么。Swanson给出了下述的项目表：（1）程序名称；（2）源程序语句条数；（3）机器代码指令条数；（

36、4）使用的程序设计语言；（5）程序的安装日期；（6）程序安装后的运行次数；（7）与程序安装后运行次数有关的处理故障的次数；（8）程序修改的层次和名称；Swanson给出了下述的项目表：（9）由于程序修改而增加的源程序语句条数；（10）由于程序修改而删除的源程序语句条数；（11）每项修改所付出的“人时”数；（12）程序修改的日期；（13）软件维护人员的姓名；（14）维护申请报告的名称；（15）维护类型；（16）维护开始时间和维护结束时间；（17）用于维护的累计“人时”数；（18）维护工作的净收益。v6.3.5 6.3.5 评价维护活动评价维护活动 缺乏有效的数据就无法评价维护活动。如果已经开始缺

37、乏有效的数据就无法评价维护活动。如果已经开始保存维护记录了，则可以对维护工作做一些定量度量。至保存维护记录了，则可以对维护工作做一些定量度量。至少可以从少可以从下述下述7 7个方面度量维护工作个方面度量维护工作：（1 1）每次程序运行时的平均出错次数；）每次程序运行时的平均出错次数；（2 2）用于每一类维护活动的总）用于每一类维护活动的总“人时人时”数；数；（3 3）每个程序、每种语言、每种维护类型所做的平均修改数；）每个程序、每种语言、每种维护类型所做的平均修改数；（4 4）维护过程中，增加或删除每条源程序语句花费的平均）维护过程中，增加或删除每条源程序语句花费的平均“人时人时”数；数；（5

38、 5）用于每种语言的平均）用于每种语言的平均“人时人时”数；数；（6 6）一张维护申请报告的平均处理时间；）一张维护申请报告的平均处理时间；（7 7）各类维护类型所占的百分比。）各类维护类型所占的百分比。软件维护的副作用软件维护的副作用v什么是软件维护的副作用什么是软件维护的副作用由于软件被修改而导致的错误或其他多余动作的发生，由于软件被修改而导致的错误或其他多余动作的发生，称为是称为是软件维护的副作用软件维护的副作用。v软件副作用的类型软件副作用的类型修改代码的副作用修改代码的副作用修改数据的副作用修改数据的副作用修改文档的副作用修改文档的副作用修改编码的副作用修改编码的副作用（1 1）对子

39、程序的删除或修改；）对子程序的删除或修改；（2 2）对语句标号的删除或修改；）对语句标号的删除或修改；（3 3）对标识符的删除或修改；）对标识符的删除或修改；（4 4）为改进程序执行性能所做的修改：）为改进程序执行性能所做的修改：（5 5）改变文件的打开或关闭；）改变文件的打开或关闭；（6 6）对逻辑运算符的修改；）对逻辑运算符的修改；（7 7）把设计的修改翻译成程序代码的修改；）把设计的修改翻译成程序代码的修改；（8 8）对判定的边界条件所做的修改。）对判定的边界条件所做的修改。为为确确保保编编码码修修改改没没有有引引入入新新的的错错误误，应应进进行行严严格格的的回回归归测测试试。一一般般情

40、情况况下下，通通过过回回归归测测试试，可可以以发发现现并并纠纠正正修修改改编编码码所所带带来来的的副副作用。作用。修改数据的副作用修改数据的副作用（1 1）重新定义局部常量或全程常量；）重新定义局部常量或全程常量；（2 2）重新定义记录格式或文件格式；）重新定义记录格式或文件格式；（3 3）改变一个数组或高阶数据结构的大小；）改变一个数组或高阶数据结构的大小；（4 4）修改全程变量；）修改全程变量；（5 5）重新初始化控制标记或指针；）重新初始化控制标记或指针；（6 6）重新排列输入输出或子程序的自变量。）重新排列输入输出或子程序的自变量。修修改改数数据据的的副副作作用用可可以以通通过过完完善

41、善的的设设计计文文档档来来加加以以限限制制。这这种种文文档档描描述述了了数数据据结结构构，并并且且提提供供了了一一种种把把数数据据元元素素、记记录录、文文件件及及其其它它结结构构与与软软件件模模块块联联系系起来的交叉对照功能。起来的交叉对照功能。修改文档的副作用修改文档的副作用v维维护护应应该该着着眼眼于于整整个个软软件件配配置置，而而不不只只是是源源程程序序代代码码的的修修改改。如如果果源源代代码码的的修修改改没没有有反反映映在在设设计计文文档档或或用用户户文档中时，就会发生文档的副作用。文档中时，就会发生文档的副作用。v每每当当对对数数据据流流图图、软软件件结结构构、模模块块算算法法过过程

42、程和和其其它它有有关关的的特特征征进进行行修修改改时时，必必须须同同时时对对相相应应的的文文档档资资料料进进行行更新。更新。v在在软软件件再再次次交交付付使使用用之之前前，对对整整个个软软件件配配置置进进行行评评审审将将大大大大减减少少文文档档的的副副作作用用。实实际际上上，某某些些维维护护申申请请的的提提出出只只是是由由于于用用户户文文档档不不够够清清楚楚。这这时时，只只需需对对文文档档进进行维护即可，并不要求修改软件设计或源程序。行维护即可，并不要求修改软件设计或源程序。6.4预防性维护预防性维护预预防防性性维维护护也也称称为为软软件件再再工工程程。目目前前，在在全全部部软软件件维维护护活

43、活动动中中，预预防防性性维维护护只只占占很很小小的的比比例例。多多数数软软件件维维护护人人员员对对预预防防性性维维护护还还缺缺乏乏足足够够的的了了解解。这这里里介介绍绍进进行行预预防防性性维护的必要性和可行性，后面介绍软件再工程的典型过程。维护的必要性和可行性，后面介绍软件再工程的典型过程。6.4.1 6.4.1 必要性必要性 预防性维护方法预防性维护方法是是MillerMiller在在“结构化翻新结构化翻新”的标题下的标题下提出来的，他把这个概念提出来的，他把这个概念定义为定义为“把今天的方法学应用到把今天的方法学应用到昨天的系统以支持明天的需求昨天的系统以支持明天的需求”。6.5.2可行性

44、可行性初看起来，在一个正在工作的程序版本已经存在的情况下，重新开发这个大型程序似乎是一种浪费，但是，考虑到下述事实预防性维护预防性维护实际上是可行的：（1）维维护护一一行行源源代代码码的的成成本本可可能能是是该该行行代代码码初初始始开开发发成成本本的的2040倍；倍；（2）使使用用现现代代设设计计概概念念重重新新设设计计软软件件体体系系结结构构（程程序序结结构构和和数数据据结结构），对未来的维护工作将有很大帮助；构），对未来的维护工作将有很大帮助；（3）由由于于软软件件原原型型（即即现现在在正正在在工工作作的的程程序序）已已经经存存在在，软软件件开开发发生产率将远远高于平均水平；生产率将远远高

45、于平均水平；（4）现现在在用用户户已已经经有有较较丰丰富富的的使使用用该该软软件件的的经经验验，因因此此，很很容容易易确确定新的需求和变更方向；定新的需求和变更方向；（5）利用软件再工程工具可以自动完成部分工作；）利用软件再工程工具可以自动完成部分工作；（6）在在完完成成预预防防性性维维护护的的过过程程中中，可可以以建建立立起起完完整整的的软软件件配配置置（文文档、程序和数据）。档、程序和数据）。当软件开发组织把软件作为产品销售时，在程序的当软件开发组织把软件作为产品销售时，在程序的“新版本新版本”中往往体现了中往往体现了预防性维护预防性维护的成果。一个大型的成果。一个大型的软件开发机构可能拥

46、有的软件开发机构可能拥有50050020002000个产品程序，可以根个产品程序，可以根据重要性把这些程序排出优先次序，然后把它们作为预据重要性把这些程序排出优先次序，然后把它们作为预防性维护的候选者加以评估。防性维护的候选者加以评估。6.5软件再工程过程软件再工程过程图6.4软件再工程过程模型在图中描绘的在图中描绘的软件再软件再工程范型是一个循环模型工程范型是一个循环模型，这意味着作为该范型组成这意味着作为该范型组成部分的每个活动都可能重部分的每个活动都可能重复进行，而且对于某个特复进行，而且对于某个特定的循环来说，过程可以定的循环来说，过程可以在完成任意一个活动之后在完成任意一个活动之后终

47、止。终止。下面介绍下面介绍软件再工程过程模型软件再工程过程模型中的每个活动中的每个活动。1.库存目录分析库存目录分析每个软件组织都应该保存其负责维护的所有应用系统的库存目录。该目录可能仅仅是包含下列信息的一个电子表格模型：应用系统的名字；应用系统的名字；最初构建它的年份；最初构建它的年份；已对它进行过的实质性修改的次数；已对它进行过的实质性修改的次数；完成这些修改所花费的总工作量；完成这些修改所花费的总工作量；最后一次实质性修改的日期；最后一次实质性修改的日期；最后一次实质性修改所花费的工作量；最后一次实质性修改所花费的工作量；它驻留的系统；它驻留的系统；和它有接口的应用系统；和它有接口的应用

48、系统；它访问的数据库；它访问的数据库；过去过去1818个月所报告的错误；个月所报告的错误；用户数量；用户数量；安装此应用系统的机器数量；安装此应用系统的机器数量；程序结构复杂程度、代码复杂程度和文档程序结构复杂程度、代码复杂程度和文档复杂程度；复杂程度；文档的质量；文档的质量；整体可维护性（用等级值表示）；整体可维护性（用等级值表示）；预期寿命（以年计）；预期寿命（以年计）；在未来在未来3636个月内的预期修改次数；个月内的预期修改次数；年度维护成本；年度维护成本；年度运行成本；年度运行成本；年度业务值；年度业务值；业务重要程度。业务重要程度。应应该该针针对对每每一一个个现现有有的的应应用用系

49、系统统收收集集上上面面列列出出的的信信息息。通通过过按按照照业业务务重重要要程程度度、寿寿命命、当当前前可可维维护护性性以以及及其其他他重重要要标标准准对对这这些些信信息息排排序序的的办办法法，可可以以选选出出软软件件再再工工程程的的候候选者，然后可以明智地为再工程分配资源。选者，然后可以明智地为再工程分配资源。必必须须注注意意，应应该该定定期期地地修修订订刚刚才才描描述述的的库库存存目目录录表表，应应用用系系统统的的状状况况（例例如如，业业务务重重要要程程度度）可可能能随随着着时时间间而而改变，因此，再工程的优先级也将发生变化。改变，因此，再工程的优先级也将发生变化。2.文档重构文档重构缺乏

50、文档或文档严重不合格，是很多老系统的通病。缺乏文档或文档严重不合格，是很多老系统的通病。面对这种状况，有下述三种做法可供选择面对这种状况，有下述三种做法可供选择：（1 1）选择）选择1 1 建立文档是非常耗费时间的，既然系统能正常工作，建立文档是非常耗费时间的，既然系统能正常工作，我们就让它保持现状好了。在某些情况下，这是一个正确我们就让它保持现状好了。在某些情况下，这是一个正确的做法。事实上，不可能为数百个计算机程序都重新建立的做法。事实上，不可能为数百个计算机程序都重新建立文档。文档。（2 2）选择）选择2 2 文档必须被更新，但是，我们只有有限的资源，因此文档必须被更新，但是，我们只有有