sw10软件维护课件.ppt

软件维护;软件维护的概念;软件维护的定义;改正性维护;适应性维护;完善性维护;实践表明，在几种维护活动中，完善性维护所占的比重最大。即大部分维护工作是改变和加强软件，而不是纠错。 完善性维护不一定是救火式的紧急维修，而可以是有计划、有预谋的一种再开发活动。 事实证明，来自用户要求扩充、加强软件功能、性能的维护活动约占整个维护工作的50％。;预防性维护;在整个软件维护阶段所花费的全部工作量中，完善性维护占了几乎一半的工作量。 软件维护活动所花费的工作占整个生存期工作量的70%以上，这是由于在漫长的软件运行过程中需要不断对软件进行修改，以改正新发现的错误、适应新的环境和用户新的要求，这些修改需要花费很多精力和时间，而且有时会引入新的错误。 ;维护在软件生 三类维护占 存期所占比例 总维护比例 ;影响维护工作量的因素;系统大小：系统越大，理解掌握起来越困难。系统越大，所执行功能越复杂。因而需要更多的维护工作量。 程序设计语言：使用强功能的程序设计语言可以控制程序的规模。语言的功能越强，生成程序的模块化和结构化程度越高，所需的指令数就越少，程序的可读性越好。;系统年龄： 老系统随着不断的修改，结构越来越乱； 维护人员经常更换，程序又变得越来越难于理解。 许多老系统在当初并未按照软件工程的要求进行开发，因而没有文档，或文档太少。 在长期的维护过程中文档在许多地方与程序实现变得不一致，在维护时就会遇到很大困难。;数据库技术的应用：使用数据库，可以简单而有效地管理和存储用户程序中的数据，还可以减少生成用户报表应用软件的维护工作量。 先进的软件开发技术：在软件开发时，若使用能使软件结构比较稳定的分析与设计技术，及程序设计技术，如面向对象技术、复用技术等，可减少大量的工作量。;其它： 应用的类型 数学模型 任务的难度 开关与标记、IF嵌套深度、索引或下标数等 对维护工作量都有影响。 许多软件在开发时并未考虑将来的修改，为软件的维护带来许多问题。;软件维护的策略;适应性维护这一类维护不可避免，可以控制。(1) 在配置管理时，把硬件、操作系统和其它相关环境因素的可能变化考虑在内。(2) 把与硬件、操作系统，以及其它外围设备有关的程序归到特定的程序模块中。 (3) 使用内部程序列表、外部文件，以及处理的例行程序包，可为维护时修改程序提供方便。;完善性维护利用前两类维护中列举的方法，也可以减少这一类维护。特别是数据库管理系统、程序生成器、应用软件包，可减少维护工作量。此外，建立软件系统的原型，把它在实际系统开发之前提供给用户。用户通过研究原型，进一步完善他们的功能要求，就可以减少以后完善性维护的需要。;维护成本;软件维护的代价是降低了生产率，在做老程序的维护时非常明显。 例如，开发每一行源代码耗资25美元，维护每一行源代码需要耗资1000美元。 维护工作量包括生产性活动（如分析和评价、设计修改和实现）和“轮转”活动（如力图理解代码在做什么、试图判明数据结构、接口特性、性能界限等）。;维护工作量的模型;模型指明，如果使用了不好的软件开发方法（未按软件工程要求做），原来参加开发的人员或小组不能参加维护，则工作量（及成本）将按指数级增加。;软件维护活动;维护机构;;维护申请提交给维护管理员，他把申请交给某个系统监督员去评价。 一旦做出评价，由修改负责人确定如何进行修改。 在修改程序的过程中，由配置管理员严格把关，控制修改的范围，对软件配置进行审计。 在维护之前，就把责任明确下来，可以减少维护过程中的混乱。;软件维护申请报告;;软件修改报告应提交修改负责人，经批准后才能开始进一步安排维护工作。;软件维护工作流程;尽管维护申请的类型不同，但都要进行同样的技术工作。 修改软件需求说明 修改软件设计 设计评审 对源程序做必要的修改 单元测试 集成测试( 回归测试) 确认测试 软件配置评审等。;在每次软件维护任务完成后进行情况评审，对以下问题做一总结：(1) 在目前情况下，设计、编码、测试中的哪一方面可以改进?(2) 哪些维护资源应该有但没有?(3) 工作中主要的或次要的障碍是什么?(4) 从维护申请的类型来看是否应当有预防性维护?情况评审对将来的维护工作如何进行会产生重要的影响。;维护档案记录;;维护评价; 每个程序、每种语言、每种维护类型的程序平均修改次数； 因为维护，增加或删除每个源程序语句所花费的平均“人时”数； 用于每种语言的平均“人时”数； 维护申请报告的平均处理时间； 各类维护申请的百分比。 据此可对开发技术、语言选择、维护工作计划、资源分配、以及其它许多方面做出判定。;程序修改的步骤及修改的副作用;