软件维护整理ppt教案资料

《软件维护整理ppt教案资料》由会员分享，可在线阅读，更多相关《软件维护整理ppt教案资料（101页珍藏版）》请在金锄头文库上搜索。

1、-软件维护,软件工程第八章,首都师范大学教育技术系 方海光2006年10月,编程大师曾说过：“哪怕程序只有三行长，总有一天你也不得不对它进行维护。”,在软件开发过程中始终强调软件的可维护性。原因是，一个应用系统由于需求和环境的变化以及自身暴露的问题，在交付用户使用后，对它进行维护是不可避免的，统计和估测结果表明，信息技术中硬件费用一般占35%，软件占65%，而软件后期维护费用有时竟高达软件总费用的80%，所有前期开发费用仅占20%。 许多大型软件公司为维护已有软件耗费大量人力、财力。因此，必须建立一套评估、控制和实施软件维护的机制，这就是本章重点讨论的内容。,内容提要,软件维护的定义 软件维护

2、的类型 结构化维护VS非结构化维护 影响软件维护工作量的因素 软件维护的过程 可维护性 软件维护的管理,软件维护的类型,根据软件维护的不同原因，软件维护可以分成三种类型： 改正性维护 适应性维护 完善性维护 预防性维护,改正性维护,在软件交付使用后，因开发时测试的不彻底、不完全，必然会有部分隐藏的错误遗留到运行阶段。 这些隐藏下来的错误在某些特定的使用环境下就会暴露出来。 为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应当进行的诊断和改正错误的过程就叫做改正性维护。,适应性维护,在使用过程中， 外部环境（新的硬、软件配置） 数据环境（数据库、数据格式、数据输入/输出方式、数

3、据存储介质） 可能发生变化。 为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。,完善性维护,在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。 为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。 这种情况下进行的维护活动叫做完善性维护。,预防性维护,预防性维护即软件再工程，是为了提高软件的可维护性、可靠性等，为以后进一步改进软件打下良好基础。 采用先进的软件工程方法对需要维护的软件或软件中的某一部分（重新）进行设计、编制和测试，称为预防性维护。,各种维护类型和维护工作量的比例,其它 维护 4 %,适应性 维 护 18-2

4、5%,改正性 维护1721%,完善性维护50%66,维护占 70.8%,改正性维护占全部维护工作量的比率已从上世纪80年代初的20%大幅度下降, 上世纪90年代初一些公司的产品差错率已接近于零!,软件维护的特点,结构化维护和非结构化维护差别巨大 软件维护的代价高昂 维护问题多,软件维护事件流,结构化维护VS非结构化维护,软件的开发过程对软件的维护产生较大的影响。 如果采用软件工程的方法进行软件开发，保证每个阶段都有完整且详细的文档，这样维护会相对容易，被称为结构化的维护。 反之，如果不采用软件工程方法开发软件，软件只有程序而欠缺文档，则维护工作变得十分困难，被成为非结构化的维护。,结构化维护V

5、S非结构化维护,交付使用,分析设计,制定计划,修改计划,编码,复审通过,文件有吗,苦读代码,找到问题,编码,复审通过,维护要求,n,y,y,y,y,n,n,n,结构化维护,非结构化维护,维护要求,配置,评价设计,计划途径,修改设计,重编程序,评价代码,？,重编程序,复查,复查,交付使用,软件,代码,结构化维护,非结构化维护,非结构化维护,在非结构化维护过程中，开发人员只能通过阅读、理解和分析源程序来了解系统功能、软件结构、数据结构、系统接口和设计约束等，这样做是十分困难的，也容易产生误解。要弄清楚整个系统，势必要花费大量的人力和物力，对源程序修改产生的后果难以估计。在没有文档的情况下，也不可能

6、进行回归测试，很难保证程序的正确性。,结构化维护,在结构化维护的过程中，所开发的软件具有各个阶段的文档，它对于理解和掌握软件的功能、性能、体系结构、数据结构、系统接口和设计约束等有很大的作用。维护时，开发人员从分析需求规格说明开始，明白软件功能和性能上的改变，对设计说明文档进行修改和复查，再根据设计修改进行程序变动，并用测试文档中的测试用例进行回归测试，最后将修改后的软件再次交付使用。这种维护有利于减少工作量和降低成本，大大提高软件的维护效率。,软件维护的代价高昂,有形代价逐年上升： 1970年软件维护费用占总费用的35%40%； 1980年软件维护费用占总费用的40%60%； 1990年软件

7、维护费用占总费用的70%80%。,软件维护的代价高昂,维护费用只不过是软件维护最明显的代价，其他一些还不明显的代价将来可能更为人们关注。其他无形的代价还有： 可用的资源被软件维护所占用。 未能及时满足用户的维护要求时引起用户不满。 维护时改动软件，引入了潜在故障，降低了软件质量。 抽调人员从事维护工作，对新的开发过程造成混乱。 导致生产率的大幅下降。,软件维护的代价高昂,用于维护工作的劳动可以划分成： 生产性活动（如，分析评价、修改设计、编写程序代码等） 非生产性活动（例如，理解程序代码功能、解释数据结构、接口特点、性能限度等）,软件维护的代价高昂,下述表达式给出了维护工作量的一个模型： 其中

8、，M是维护的总工作量，P是生产性工作量，K是经验常数，c是复杂程度，d是维护人员对软件的熟悉程度 上述模型表明，如果软件开发没有运用软件工程方法学，而且原来的开发人员未能够参与到维护工作之中，则维护工作量和费用将指数增加。,软件维护的问题,与软件维护有关的大多数问题都可归因于软件定义和开发方法上的不足。 软件开发时采用急功近利，还是放眼未来的态度，对软件维护影响极大。 一般说来，软件开发若不严格遵循软件开发标准，软件维护就会遇到许多困难。,软件维护的问题,下面列出了和软件维护有关的部分问题： 理解别人的代码通常是非常困难的，而且难度随着软件配置成分的缺失而迅速增加； 需要维护的软件通常往往没有

9、合格的文档，或文档资料显然不足。-认识到文档仅仅是第一步，容易理解且和程序保持一致的文档才是真正具有价值的； 当软件要求维护时，不能指望开发人员给我们仔细说明软件。由于维护持续时间很长，因此当需要解释软件时候，往往开发人员已经不在附近了； ,上述种种问题在现有没有采用软件工程思想开发出来的软件中，都或多或少存在。,影响软件维护工作量的因素,在软件维护中，影响维护工作量的因素主要有以下六种： 系统的大小 系统规模越大，其功能就越复杂，软件维护的工作量也随之增大。 程序设计语言 使用强功能的程序设计语言可以控制程序的规模。语言的功能越强，生成程序的模块化和结构化程度越高，所需的指令数就越少，程序的

10、可读性越好。,影响软件维护工作量的因素,系统年龄 老系统比新系统需要更多的维护工作量 。因为多次的修改可能造成系统结构变得混乱，由于维护人员经常更换，程序变得越来越难于理解，加之系统开发时文档不齐全，或在长期的维护过程中文档在许多地方与程序实现变得不一致，从而使维护变得十分困难。 数据库技术的应用 使用数据库，可以简单而有效地管理和存储用户程序中的数据，还可以减少生成用户报表应用软件的维护工作量。,影响软件维护工作量的因素,先进的软件开发技术 在软件开发过程中，如果采用先进的分析设计技术和程序设计技术，如面向对象技术、复用技术等，可减少大量的维护工作量。 其它一些因素 如应用的类型、数学模型、

11、任务的难度、开关与标记、IF嵌套深度、索引或下标数等，对维护工作量也有影响。,软件维护的过程,软件维护工作在维护申请提出之前就开始了，它包括： 建立维护组织，强制报告和评估的过程； 为每个维护申请确定标准化的事件序列； 制定保存维护活动记录的制度和有关复审及评估的标准。,维护阶段的工作事件流,维护组织,维护决策机构,维护管理员,系统管理员,维护人员,配置管理员,维护申请,每个维护申请通过维护管理员转告给系统管理员，系统管理员一般都是对程序(某一部分)特别熟悉的技术人员，他们对维护申请及可能引起的软件修改进行评估，并向修改控制决策机构(一个或一组管理者)报告，由它最后确定是否采取行动。,在维护活

12、动开始之前就明确维护责任是十分必要的，可以大大地减少维护过程中可能出现的混乱。,维护团队组织,维护报告MRF,应该用标准的格式来表达维护要求。软件维护人员通常提供给用户空白的维护请求表（报告）即软件问题报告，该报告（表）由要求一项维护活动的用户填写。 如遇到什么错误，用户需要详细描述错误出现的现场信息(包括输入数据、列表文件和其他有关信息)； 对适应性维护、完善性维护应该给出一个简短的需求规格说明书。最终由维护管理员和系统管理员评价用户用户提出的维护请求表。,一个维护申请被核准后，维护请求表就成为外部文档，视作规划本次维护任务的依据。,软件维护请求报告,软件修改报告(SCR),依据维护请求表，

13、软件组织内部应该制定出一个软件修改报告，它给出下述信息： 满足维护请求表中提出的要求所需的工作量； 维护要求的性质； 维护要求的优先次序； 与修改有关的背景数据。 在拟定进一步维护计划前，把软件修改报告提交控制决策机构审查批准。,有 无,有 无,软件修改报告(SCR),软件维护的工作流,软件维护工作流,虽然每种维护请求类型着眼点不同，但总的维护方法是相同的。 维护工作最后一步是复审，主要审查修改过的软件配置，以验证软件结构中的所有成分的功能，保证满足维护请求表中的要求。,情况复审,当一项软件维护任务完成之后，进行一次情况复审不无裨益。情况复审主要考虑下列问题: 依照当前状态，在设计、编码和测试

14、的哪些方面还能用其他方法进行? 哪些维护资源可用但未用？ 这次维护活动中主要(或次要)的障碍有哪些? 在维护请求中有预防性维护吗? 情况复审的目的在于促进未来的维护工作,同时也为有效管理软件组织提供重要的反馈信息。,软件维护记录的保存,有效的保存维护记录是极端重要的。 保存维护记录的第一个问题就是那些数据值得保存？ Swanson为我们指出了下述内容：程序标识、源语句数、机器指令数、使用的程序设计语言、软件安装的日期、自安装以来软件运行的次数、自安装以来软件失败的次数、程序变动的层次和标识、因程序变动而增加的源语句数、因程序变动而删除的源语句数、每个改动消耗的人时数、程序改动的日期、软件工程师

15、的名称、维护要求的标识、维护类型、维护开始和完成的时间、用于维护的累计人时数、与完成的维护相关联的纯收益。 应该为每项维护工作都收集上述数据。可以利用这些数据构成一个维护数据库。,软件维护记录,评价维护活动,缺乏有效的数据就无法评价软件维护活动。 如果已经开始保存维护记录，则可以对维护工作做一些定量度量，至少可以从如下7方面进行评价： 每次程序运行平均失败的次数； 用于每一类维护活动的总人时数； 平均每个程序、每种语言、每种维护类型所必需的程序变动数； 维护过程中增加或删除源语句平均花费的人时数； 维护每种语言平均花费的人时数； 一张维护要求表的平均周转时间； 不同维护类型所占的比例；,根据这

16、些统计量可对开发技术、编程语言，以及对维护工作量的预测与资源分配等诸多方面的决策进行评价。,软件可维护性,软件可维护性即软件被理解、改正、调整和改进的难易程度。 可维护性是指导软件工程各个阶段工作的一条基本原则，也是软件工程追求的目标之一。,影响软件可维护性的因素,软件的可维护性受各种因素的影响：设计、编码和测试时漫不经心，软件配置不全，都会给维护带来困难。除了与开发方法有关的因素外，还有下列与开发环境有关的因素: 是否拥有一组训练有素的软件人员; 系统结构是否可理解; 是否使用标准的程序设计语言; 是否使用标准的操作系统; 文档的结构是否标准化; 测试用例是否合适; 是否已有嵌入系统的调试工具; 是否有一台计算机可用于维护。 除此之外，软件开发时的原班人马是否能参加维护也是一个值得考虑的因素。,软件可维护性的度量,软件可维护性与软件质量和可靠性一样是难于量化的