搜索
STARTINPUT（A,B,C)IFA5THENX=10ELSEX=1ENDIFIFB10THENY=20ELSEY=2ENDIFIFC15THENZ=30ELSEZ=3ENDIFPRINT(X,Y,Z)STOP习题7.4.3第8章维护8.1软件维护的定义及特点8.2软件的可维护性8.3软件维护实施过程8.4预防性维护8.5软件再工程过程第六章软件维护学习内容：在软件的开发工作已完成并把软件产品交付给用户使用之后，就进入了软件维护阶段。这个阶段的工作目标是保证软件在一个相当长的时期内能够正常运行，因此对软件的维护就成为必不可少的了。软件维护需要的工作量非常大。平均说来，大型软件的维护成本高达开发成本的四倍左右。目前国外许多软件开发组织把80%以上的人力用于维护已有的软件，而且随着软件数量增多和使用寿命延长，这个百分比还在持续上升。将来维护工作甚至可能会束缚住软件开发组织的手脚，使他们没有余力开发新的软件。8.1软件维护的定义8.1.1软件维护的内容所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。我们可以通过描述软件交付使用后可能进行的下述四项活动，具体地定义软件维护。1.改正性维护通常，在软件开发过程中所进行的测试都是不完全、不彻底的，软件中必然会有一些潜伏的错误被带到运行阶段来。用户常常将把他们遇到的问题报告给软件维护人员，要求解决。我们把诊断和改正软件错误的过程称为改正性维护。例如，在软件交付用户使用之后，解决在开发时没有测试所有可能的执行通路而带来的问题；2.适应性维护计算机科学技术领域的各个方面都在迅速进步，大约每过38个月就有新一代的硬件宣告出现；另一方面，应用软件的使用寿命却很容易超过十年，远远长于最初开发这个软件时的运行环境的寿命。因此，适应性维护就是为了和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动。例如，适应性维护可以是修改原在xp操作系统中运行的程序，使之能在vista操作系统中运行。3.完善性维护在使用软件的过程中，用户往往提出增加新功能或改变某些已有功能的要求，还可能提出提高程序性能的要求。为了满足这类要求而修改软件的活动，称为完善性维护。例如，在储蓄系统交付银行使用之后，增加扣除利息税的功能；缩短系统的响应时间，使之达到新的要求；改变现有程序输出数据的格式，以方便用户；在正在运行的软件中增加联机求助功能等，都是完善性维护。4.预防性维护当为了提高未来的可维护性或可靠性，或为了给未来的改进工作奠定更好的基础而修改软件时，就出现了第四类维护活动，这类维护活动称为预防性维护。通常，把预防性维护定义为：“把今天的方法学应用于昨天的系统以满足明天的需要”。也就是说，预防性维护就是采用先进的软件工程方法对需要维护的软件或软件中的某一部分，主动地进行重新设计、编码和测试。在维护阶段的最初一二年，改正性维护的工作量往往比较大。随着在软件运行过程中错误发现率迅速降低并趋于稳定，就进入了正常使用期间。但是，由于用户经常提出改造软件的要求，适应性维护和完善性维护的工作量逐渐增加，而且在这种维护过程中往往又会引入新的错误，从而进一步加大了维护的工作量。从上述关于软件维护的定义不难看出，软件维护绝不仅限于纠正使用中发现的错误，事实上在全部维护活动中一半以上是完善性维护。国外的统计数字表明：完善性维护占全部维护活动的50%～66%改正性维护占17%～21%，适应性维护占18%～25%，其他维护活动只占4%左右。返回目录8.1.2软件维护的的特点8.1.2.1结构化维护与非结构化维护差别悬殊8.1.2.2维护的代价高昂8.1.2.3维护的问题很多8.1.2.1结构化维护与非结构化维护差别悬殊如果软件配置的惟一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难（诸如软件结构、全程数据结构、系统接口、性能或设计约束等微妙的特点是难于搞清的，而且常常误解了这一类特点）。最终对程序代码所做的改动的后果是难于估量的。因为没有测试方面的文档，所以不可能进行回归测试。这就是非结构化维护，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果---并正在为此而付出代价（浪费精力和受挫折）。非结构化维护(上图右侧)如果有一个完整的软件配置存在，那么维护工作从评价设计文档开始，确定软件重要的结构特点、性能特点以及接口特点；估量要求的改动将带来的影响，并且计划实施途径。然后首先修改设计并且对所做的修改进行仔细复查。接下来编写相应的源程序代码；使用在测试说明书中包含的信息进行回归测试；最后，把修改后的软件再次交付使用。上面描述的事件构成结构化维护，它是在软件开发的早期应用软件工程方法学的结果。（它确实能减少精力的浪费并且能提高维护的总体质量。）8.2.2维护的代价高昂在过去的几十年中，软件维护的费用稳步上升。1970年用于维护已有软件的费用只占软件总预算的35%～40%，1980年上升为40%～60%，1990年上升为70%～80%。维护费用只不过是软件维护的最明显的代价，其他一些现在还不明显的代价将来可能更为人们所关注。因为可用的资源必须供维护任务使用，以致耽误甚至丧失了开发新软件的良机，这是软件维护的一个无形的代价。其他无形的代价还有：（了解）●当看来合理的有关改错或修改的要求不能及时满足时将引起用户不满；●由于维护时的改动，在软件中引入了潜伏的故障，从而降低了软件的质量；●当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱。8.1.2.3维护的问题很多与软件维护有关的绝大多数问题，都可归因于软件定义和软件开发的方法有缺点。在软件生命周期的头两个时期没有严格而又科学的管理和规划，几乎必然会导致在最后阶段出现问题。下面列出和软件维护有关的部分问题：●读懂别人写的程序通常非常困难。而且困难程度随着软件配置成分的减少而迅速增加。如果仅有程序代码没有说明文档，则会出现严重的问题。●需要维护的软件往往没有合格一致的文档，或者文档资料显著不足。认识到软件必须有文档仅仅是第一步，容易理解并且和程序代码完全一致的文档才真正有价值。●当要求对软件进行维护时，不能指望由开发人员给我们仔细说明软件。由于维护阶段持续的时间很长，因此，当需要解释软件时，往往原来写程序的人已不在现场了。●绝大多数软件在设计时没有考虑将来的修改。除非使用强调模块独立原理的设计方法学，否则修改软件既困难又容易发生差错。●软件维护不是一项吸引人的工作。形成这种观念很大程度上是因为维护工作经常遭受挫折。上述种种困难存在于现有的没采用软件工程思想开发出来的软件中。不应该把一种科学的方法学看做万应灵药，但是，软件工程至少部分地解决了与维护有关的每一个问题。返回目录8.2软件的可维护性8.2.1软件的可维护性-----指软件能够被维护人员理解、改正、适应和完善以适应新的环境的难易程度。决定软件可维护性的因素1.可理解性可理解性表现为外来读者理解软件的结构、接口、功能和内部过程的难易程度。影响软件可理解性的重要因素有：模块化、结构化设计、详细的设计文档资料、源代码内部文档、良好的程序设计语言等。2.可测试性在设计开发阶段应该注意尽量把软件设计成容易测试和容易诊断的，可用的测试工具和调试工具对测试和诊断非常重要。3.可修改性软件的可修改程度与软件设计阶段采用的原则和策略是直接相关的。如：模块的耦合、内聚、控制范围和作用范围、局部化程度都直接影响软件的可修改性。4.可移植性把程序从一种环境转移到另一种环境的难易程度5.可重用性同一事物不做修改或稍加改动就可在不同环境中多次重复用决定软件可维护性的最终因素是软件设计阶段所采用的方法，以及软件文档资料的好坏。提高软件的可维护性是软件工程的一个重要目标。8.2.2文档：影响软件可维护性的决定因素1.用户文档：描述系统功能和使用方法，并不关心系统实现手段（用户角度）2.系统文档：描述系统设计、实现和测试各方面的内容。总的说来，软件文档应该满足下述要求：从用户角度出发（1）必须说明系统能做什么（功能描述）；（2）必须描述如何使用（使用手册）这个系统，没有这种描述即使是最简单的系统也无法使用；（3）必须描述怎样安装（安装文档）和管理（参考手册、操作用指南）这个系统；从开发者角度出发（1）必须描述系统需求和设计；（2）必须描述系统的实现和测试，以便使系统成为可维护的。返回目录8.3软件维护实施过程维护组织维护报告维护的事件流保存维护记录评价维护活动8.3软件维护实施过程首先必须建立一个维护组织，随后必须确定报告和评价的过程，而且必须为每个维护要求规定一个标准化的事件序列。此外，还应该建立一个适用于维护活动的记录保管过程，并且规定复审标准。8.3.1维护组织虽然通常并不需要建立正式的维护组织，但是，即使对于一个小的软件开发团体而言，非正式地委托责任也是绝对必要的。维护机构成员一般包括：配置管理员、维护控制员、系统管理员、一般维护工作人员。每个维护要求都通过维护管理员转交给相应的系统管理员去评价，见下页图示。维护机构…维护要求（软件问题报告）维护管理员系统管理员软件系统变化授权人图8.1维护组织8.3.2维护报告应该用标准化的格式表达所有软件维护要求。软件维护人员通常给用户提供空白的维护要求表——有时称为软件问题报告表，这个表格由要求一项维护活动的用户填写。如果遇到了一个错误，那么必须完整描述导致出现错误的环境（包括输入数据，全部输出数据，以及其他有关信息）。对于适应性或完善性的维护要求，应该提出一个简短的需求说明书。如前所述，由维护管理员和系统管理员评价用户提交的维护要求表。维护要求表是一个外部产生的文件，它是计划维护活动的基础。软件组织内部应该制定出一个软件修改报告，它给出下述信息：（1）满足维护要求表中提出的要求所需要的工作量；（2）维护要求的性质；（3）这项要求的优先次序；（4）与修改有关的事后数据。在拟定进一步的维护计划之前，把软件修改报告提交给变化授权人审查批准。8.3.3维护的事件流图6.3描绘了由一项维护要求而引出的一串事件。1、首先应该确定要求进行的维护的类型。用户常常把一项要求看作是为了改正软件的错误（即改正性维护），而开发人员可能把同一项要求看作是适应性或完善性维护。当存在不同意见时必须协商解决。评价错误严重程度改正性确定类型维护要求评价优先次序完善性或适应性开始问题分析严重不严重安排改正性维护错误改正目录开始分析维护任务复审开发目录低高人员安排修改后的软件通过后交付使用的软件人员安排从图6.3描绘的事件流看到：2、对改（校）正性维护要求的处理，从估量错误的严重程度开始。如果是一个严重的错误（例如，一个关键性的系统不能正常运行），则在系统管理员的指导下分派人员，并且立即开始问题分析过程。如果错误并不严重，那么改正性的维护和其他要求软件开发资源的任务一起统筹安排。3、适应性维护和完善性维护的要求沿着相同的事件流通路前进。应该确定每个维护要求的优先次序，并且安排要求的工作时间，就好像它是另一个开发任务一样，如果一项维护要求的优先次序非常高，可能立即开始维护工作。4、不管维护类型如何，都需要进行同样的技术工作。这些工作包括修改软件设计、复查、必要的代码修改、单元测试和集成测试（包括使用以前的测试方案的回归测试），验收测试和复审。不同类型的维护强调的重点不同，但是基本途径是相同的。维护事件流中最后一个事件是复审，它再次检验软件配置的所有成分的有效性，并且保证事实上满足了维护要求表中的要求。5、当然，也有并不完全符合上述事件流的维护要求。当发生恶性的软件问题时，就出现所谓的“救火”维护要求，这种情况需要立即把资源用来解决问题。（如果对一个组织来说，“救火”是常见的过程，那么就必须怀疑它的管理能力和技术能力。）8.3.4保存维护记录在处理每项维护要求的过程中，应该收集和保存与维护工作有关的数据（了解）Swanson给出了下述的项目表：（1）程序名称；（2）源程序语句条数；（3）机器代码指令条数；（4）使用的程