《 软件工程 》

1. 《软件工程》 软件维护 陈巧丽

2. 第六章 软件维护 学习内容： 6.1 软件维护的内容及特点 6.2 软件的可维护性 6.3 维护任务的实施 6.4 预防性维护 6.5 软件再工程过程

3. 在软件的开发工作已完成并把软件产品交付给用户使用之后，就进入了软件维护阶段。这个阶段的工作目标是保证软件在一个相当长的时期内能够正常运行，因此对软件的维护就成为必不可少的了。在软件的开发工作已完成并把软件产品交付给用户使用之后，就进入了软件维护阶段。这个阶段的工作目标是保证软件在一个相当长的时期内能够正常运行，因此对软件的维护就成为必不可少的了。 软件维护需要的工作量非常大。平均说来，大型软件的维护成本高达开发成本的四倍左右。目前国外许多软件开发组织把60%以上的人力用于维护已有的软件，而且随着软件数量增多和使用寿命延长，这个百分比还在持续上升。将来维护工作甚至可能会束缚住软件开发组织的手脚，使他们没有余力开发新的软件。

4. 6.1 软件维护的内容及特点 6.1.1 软件维护的内容 所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。 我们可以通过描述软件交付使用后可能进行的下述四项活动，具体地定义软件维护。 返回目录

5. 1. 改正性维护 通常，在软件开发过程中所进行的测试都是不完全、不彻底的，软件中必然会有一些潜伏的错误被带到运行阶段来。用户常常将把他们遇到的问题报告给软件维护人员，要求解决。 我们把诊断和改正软件错误的过程称为改正性维护。例如，在软件交付用户使用之后，解决在开发时没有测试所有可能的执行通路而带来的问题；解决程序中遗漏对文件中最后一个记录的处理的错误等。

6. 2. 适应性维护 计算机科学技术领域的各个方面都在迅速进步，大约每过36个月就有新一代的硬件宣告出现；另一方面，应用软件的使用寿命却很容易超过十年，远远长于最初开发这个软件时的运行环境的寿命。因此，适应性维护就是为了和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动。 例如，适应性维护可以是修改原在DOS操作系统中运行的程序，使之能在Windows操作系统中运行；修改两个程序，使它们能够使用相同的记录结构；修改程序，使它适用于另外一种终端设备。

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

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

9. 在维护阶段的最初一二年，改正性维护的工作量往往比较大。随着在软件运行过程中错误发现率迅速降低并趋于稳定，就进入了正常使用期间。但是，由于用户经常提出改造软件的要求，适应性维护和完善性维护的工作量逐渐增加，而且在这种维护过程中往往又会引入新的错误，从而进一步加大了维护的工作量。在维护阶段的最初一二年，改正性维护的工作量往往比较大。随着在软件运行过程中错误发现率迅速降低并趋于稳定，就进入了正常使用期间。但是，由于用户经常提出改造软件的要求，适应性维护和完善性维护的工作量逐渐增加，而且在这种维护过程中往往又会引入新的错误，从而进一步加大了维护的工作量。 从上述关于软件维护的定义不难看出，软件维护绝不仅限于纠正使用中发现的错误，事实上在全部维护活动中一半以上是完善性维护。国外的统计数字表明： 完善性维护占全部维护活动的50%～66% 改正性维护占17%～21%， 适应性维护占18%～25%， 其他维护活动只占4%左右。

10. 软件维护策略 针对上一小节所述的三种典型的维护活动，JamesMartin等人提出了一些可以减少维护成本的策略。下面学习主要的软件维护策略。 1. 降低改正性维护成本的策略 显然，软件中包含的错误越少，改正性维护的成本也就越低，但是，要生成100%可靠的软件通常成本太高，并不一定合算。然而通过使用先进技术仍然可以大大提高软件的可靠性，从而减少改正性维护的需求。

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

12. 3. 降低完善性维护成本的策略 上述的减少前两类维护成本的策略，通常也能降低完善性维护的成本。特别是数据库管理系统、程序自动生成系统、软件开发环境、第四代语言和应用软件包，可明显减少维护工作量。 此外，在需求分析过程中准确地预测用户将来可能提出的需求，并且在设计时为将来可能提出的需求预先做准备，显然是降低完善性维护成本的有力措施。 在实际开发软件之前，建立软件的原型并让用户试用，以进一步完善他们对软件的功能需求，也能显著减少软件交付使用之后的完善性维护需求。

13. 6.1.2 软件维护的的特点 图6.1描绘了面对一项维护要求时，不同的软件配置所导致的不同工作流程。 图6.1结构化维护与 非结构化维护的对比 非结构化维护 结构化维护 返回目录

14. 6.1.2.1 结构化维护与非结构化维护差别悬殊 如果软件配置的惟一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难（诸如软件结构、全程数据结构、系统接口、性能或设计约束等微妙的特点是难于搞清的，而且常常误解了这一类特点）。最终对程序代码所做的改动的后果是难于估量的。 因为没有测试方面的文档，所以不可能进行回归测试。这就是非结构化维护，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果---并正在为此而付出代价（浪费精力和受挫折）。 非结构化维护(上图右侧)

15. 如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特点以及接口特点；估量要求的改动将带来的影响，并且计划实施途径。然后首先修改设计并且对所做的修改进行仔细复查。接下来编写相应的源程序代码；使用在测试说明书中包含的信息进行回归测试；最后，把修改后的软件再次交付使用。如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特点以及接口特点；估量要求的改动将带来的影响，并且计划实施途径。然后首先修改设计并且对所做的修改进行仔细复查。接下来编写相应的源程序代码；使用在测试说明书中包含的信息进行回归测试；最后，把修改后的软件再次交付使用。 上面描述的事件构成结构化维护，它是在软件开发的早期应用软件工程方法学的结果。（它确实能减少精力的浪费并且能提高维护的总体质量。）

16. 6.1.2.2 维护的代价高昂 在过去的几十年中，软件维护的费用稳步上升。1970年用于维护已有软件的费用只占软件总预算的35%～40%，1980年上升为40%～60%，1990年上升为70%～80%。 维护费用只不过是软件维护的最明显的代价，其他一些现在还不明显的代价将来可能更为人们所关注。因为可用的资源必须供维护任务使用，以致耽误甚至丧失了开发新软件的良机，这是软件维护的一个无形的代价。其他无形的代价还有： ●当看来合理的有关改错或修改的要求不能及时满足时将引起用户不满； ● 由于维护时的改动，在软件中引入了潜伏的故障，从而降低了软件的质量； ● 当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱。

17. 软件维护的最后一个代价是生产率的大幅度下降，这种情况在维护旧程序时常常遇到。例如，据Gausler在1976年的报道，美国空军的飞行控制软件每条指令的开发成本是75美元，然而维护成本大约是每条指令4000美元，也就是说，生产率下降了50倍以上。软件维护的最后一个代价是生产率的大幅度下降，这种情况在维护旧程序时常常遇到。例如，据Gausler在1976年的报道，美国空军的飞行控制软件每条指令的开发成本是75美元，然而维护成本大约是每条指令4000美元，也就是说，生产率下降了50倍以上。 用于维护工作的劳动（活动）可以分成生产性活动（例如，分析评价，修改设计和编写程序代码等）和非生产性活动（例如，理解程序代码的功能，解释数据结构、接口特点和性能限度等）。

18. 下述公式给出维护工作量的一个模型: 其中：M是维护用的总工作量 P是生产性工作量 K是经验常数 c是复杂程度（非结构化设计和缺少文档都会增加软件的复杂程度） d是维护人员对软件的熟悉程度。 上面的模型表明，如果软件的开发途径不好（即，没有使用软件工程方法学），而且原来的开发人员不能参加维护工作，那么维护工作量（和费用）将指数地增加。 M＝P＋K×exp（c－d）

19. 6.1.2.3 维护的困难性 与软件维护有关的绝大多数困难，都可归因于软件定义和软件开发的方法有缺点。在软件生命周期的头两个时期没有严格而又科学的管理和规划，几乎必然会导致在最后阶段出现问题。下面列出和软件维护有关的部分问题： ● 读懂别人写的程序通常非常困难。而且困难程度随着软件配置成分的减少而迅速增加。如果仅有程序代码没有说明文档，则会出现严重的问题。 ● 需要维护的软件往往没有合格一致的文档，或者文档资料显著不足。认识到软件必须有文档仅仅是第一步，容易理解并且和程序代码完全一致的文档才真正有价值。

20. ● 当要求对软件进行维护时，不能指望由开发人员给我们仔细说明软件。由于维护阶段持续的时间很长，因此，当需要解释软件时，往往原来写程序的人已不在现场了。 ● 绝大多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理的设计方法学，否则修改软件既困难又容易发生差错。 ● 软件维护不是一项吸引人的工作。形成这种观念很大程度上是因为维护工作经常遭受挫折。 上述种种困难存在于现有的没采用软件工程思想开发出来的软件中。不应该把一种科学的方法学看做万应灵药，但是，软件工程至少部分地解决了与维护有关的每一个问题。

21. 6.2 软件的可维护性 • 6.2.1 软件的可维护性 • -----指软件能够被维护人员理解、改正、适应和完善以适应新的环境的难易程度。 • 决定软件可维护性的因素 • 维护就是在软件交付使用后进行的修改，修改之前必须理解修改的对象，修改之后应该进行必要的测试，以保证所做的修改是正确的。如果是改正性维护，还必须预先进行调试以确定错误。因此，影响软件可维护性的因素主要有下述七个： 返回目录

22. 1. 可理解性 2. 可测试性 3. 可修改性 4. 可靠性 5. 可移植性 6. 可重用性 7. 效率

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

24. 总的说来，软件文档应该满足下述要求： （1）必须描述如何使用这个系统，没有这种描述即使是最简单的系统也无法使用； （2）必须描述怎样安装和管理这个系统； （3）必须描述系统需求和设计； （4）必须描述系统的实现和测试，以便使系统成为可维护的。

25. 6.2.3 提高软件可维护性的方法 从以下五方面解决： 1．建立明确的软件质量标准 2．利用先进的软件技术和工具 3．建立明确的质量保证制度 4．选择可维护的程序设计语言 5．改进软件的文档。

26. 6.2.4 可维护性复审 可维护性是所有软件都应该具备的基本特点。在软件工程过程的每一个阶段都应该考虑并努力提高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。

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

28. 维护机构

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

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

31. 维护要求表是一个外部产生的文件，它是计划维护活动的基础。软件组织内部应该制定出一个软件修改报告，它给出下述信息：维护要求表是一个外部产生的文件，它是计划维护活动的基础。软件组织内部应该制定出一个软件修改报告，它给出下述信息： （1）满足维护要求表中提出的要求所需要的工作量； （2）维护要求的性质； （3）这项要求的优先次序； （4）与修改有关的事后数据。 在拟定进一步的维护计划之前，把软件修改报告提交给变化授权人审查批准。

32. 6.3.3 维护的事件流 图6.3描绘了由一项维护要求而引出的一串事件。1、首先应该确定要求进行的维护的类型。用户常常把一项要求看作是为了改正软件的错误（即改正性维护），而开发人员可能把同一项要求看作是适应性或完善性维护。当存在不同意见时必须协商解决。

33. 从图6.3描绘的事件流看到： 2、对改（校）正性维护要求的处理，从估量错误的严重程度开始。如果是一个严重的错误（例如，一个关键性的系统不能正常运行），则在系统管理员的指导下分派人员，并且立即开始问题分析过程。如果错误并不严重，那么改正性的维护和其他要求软件开发资源的任务一起统筹安排。 3、适应性维护和完善性维护的要求沿着相同的事件流通路前进。应该确定每个维护要求的优先次序，并且安排要求的工作时间，就好像它是另一个开发任务一样，如果一项维护要求的优先次序非常高，可能立即开始维护工作。

34. 4、不管维护类型如何，都需要进行同样的技术工作。这些工作包括修改软件设计、复查、必要的代码修改、单元测试和集成测试（包括使用以前的测试方案的回归测试），验收测试和复审。不同类型的维护强调的重点不同，但是基本途径是相同的。维护事件流中最后一个事件是复审，它再次检验软件配置的所有成分的有效性，并且保证事实上满足了维护要求表中的要求。4、不管维护类型如何，都需要进行同样的技术工作。这些工作包括修改软件设计、复查、必要的代码修改、单元测试和集成测试（包括使用以前的测试方案的回归测试），验收测试和复审。不同类型的维护强调的重点不同，但是基本途径是相同的。维护事件流中最后一个事件是复审，它再次检验软件配置的所有成分的有效性，并且保证事实上满足了维护要求表中的要求。 5、当然，也有并不完全符合上述事件流的维护要求。当发生恶性的软件问题时，就出现所谓的“救火”维护要求，这种情况需要立即把资源用来解决问题。（如果对一个组织来说，“救火”是常见的过程，那么就必须怀疑它的管理能力和技术能力。）

35. 在完成软件维护任务之后，进行处境复查常常是有好处的。一般说来，这种复查试图回答下述问题：在完成软件维护任务之后，进行处境复查常常是有好处的。一般说来，这种复查试图回答下述问题： ●在当前处境下设计、编码或测试的哪些方面能用不同方法进行? ● 哪些维护资源是应该有而事实上却没有的? ● 对于这项维护工作什么是主要的、次要的障碍是什么? ● 要求的维护类型中有预防性维护吗? 处境复查对将来维护工作的进行有重要影响，而且所提供的反馈信息对有效地管理软件组织十分重要。

36. 6.3.4 保存维护记录 对于软件生命周期的所有阶段而言，以前记录保存都是不充分的，而软件维护则根本没有记录保存下来。由于这个原因，我们往往不能估价维护技术的有效性，不能确定一个产品程序的“优良”程度，而且很难确定维护的实际代价是什么。

37. Swanson给出了下述的项目表： （1）程序名称； （2）源程序语句条数； （3）机器代码指令条数； （4）使用的程序设计语言； （5）程序的安装日期； （6）程序安装后的运行次数； （7）与程序安装后运行次数有关的处理故障的次数； （8）程序修改的层次和名称；

38. Swanson给出了下述的项目表： （9）由于程序修改而增加的源程序语句条数； （10）由于程序修改而删除的源程序语句条数； （11）每项修改所付出的“人时”数； （12）程序修改的日期； （13）软件维护人员的姓名； （14）维护申请报告的名称； （15）维护类型； （16）维护开始时间和维护结束时间； （17）用于维护的累计“人时”数； （18）维护工作的净收益。

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

40. 软件维护的副作用 • 什么是软件维护的副作用 • 由于软件被修改而导致的错误或其他多余动作的发生，称为是软件维护的副作用。 • 软件副作用的类型 • 修改代码的副作用 • 修改数据的副作用 • 修改文档的副作用

41. 修改编码的副作用 （1）对子程序的删除或修改； （2）对语句标号的删除或修改； （3）对标识符的删除或修改； （4）为改进程序执行性能所做的修改： （5）改变文件的打开或关闭； （6）对逻辑运算符的修改； （7）把设计的修改翻译成程序代码的修改； （8）对判定的边界条件所做的修改。 为确保编码修改没有引入新的错误，应进行严格的回归测试。一般情况下，通过回归测试，可以发现并纠正修改编码所带来的副作用。

42. 修改数据的副作用 （1）重新定义局部常量或全程常量； （2）重新定义记录格式或文件格式； （3）改变一个数组或高阶数据结构的大小； （4）修改全程变量； （5）重新初始化控制标记或指针； （6）重新排列输入输出或子程序的自变量。 修改数据的副作用可以通过完善的设计文档来加以限制。这种文档描述了数据结构，并且提供了一种把数据元素、记录、文件及其它结构与软件模块联系起来的交叉对照功能。

43. 修改文档的副作用 • 维护应该着眼于整个软件配置，而不只是源程序代码的修改。如果源代码的修改没有反映在设计文档或用户文档中时，就会发生文档的副作用。 • 每当对数据流图、软件结构、模块算法过程和其它有关的特征进行修改时，必须同时对相应的文档资料进行更新。 • 在软件再次交付使用之前，对整个软件配置进行评审将大大减少文档的副作用。实际上，某些维护申请的提出只是由于用户文档不够清楚。这时，只需对文档进行维护即可，并不要求修改软件设计或源程序。

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

45. 6.5.2 可行性 初看起来，在一个正在工作的程序版本已经存在的情况下，重新开发这个大型程序似乎是一种浪费，但是，考虑到下述事实预防性维护实际上是可行的： （1）维护一行源代码的成本可能是该行代码初始开发成本的20～40倍； （2）使用现代设计概念重新设计软件体系结构（程序结构和数据结构），对未来的维护工作将有很大帮助； （3）由于软件原型（即现在正在工作的程序）已经存在，软件开发生产率将远远高于平均水平； （4）现在用户已经有较丰富的使用该软件的经验，因此，很容易确定新的需求和变更方向； （5）利用软件再工程工具可以自动完成部分工作； （6）在完成预防性维护的过程中，可以建立起完整的软件配置（文档、程序和数据）。

46. 当软件开发组织把软件作为产品销售时，在程序的“新版本”中往往体现了预防性维护的成果。一个大型的软件开发机构可能拥有500～2000个产品程序，可以根据重要性把这些程序排出优先次序，然后把它们作为预防性维护的候选者加以评估。

47. 图6.4 软件再工程过程模型 6.5 软件再工程过程 在图6.4中描绘的软件再工程范型是一个循环模型，这意味着作为该范型组成部分的每个活动都可能重复进行，而且对于某个特定的循环来说，过程可以在完成任意一个活动之后终止。 返回目录

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

49. ● 用户数量； ● 安装此应用系统的机器数量； ● 程序结构复杂程度、代码复杂程度和文档复杂程度； ● 文档的质量； ● 整体可维护性（用等级值表示）； ● 预期寿命（以年计）； ● 在未来36个月内的预期修改次数； ● 年度维护成本； ● 年度运行成本； ● 年度业务值； ● 业务重要程度。

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