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