第1章软件维护ppt课件.ppt

第11章软件维护 主要内容 软件维护的概念及种类 软件维护的特点 软件维护的实施过程与管理方法 软件的可维护性和提高软件可维护性的方法 软件维护的副作用 本章重点 软件维护的概念及种类 软件维护的实施过程与管理方法 本章难点 软件的可维护性及提高软件可维护性的方法 第11章软件维护 11 1软件维护的种类11 2软件维护的特点11 3软件维护的实施11 4软件的可维护性11 5软件维护的副作用 11 1软件维护的种类 在软件运行 维护阶段对软件产品所进行的修改就是维护 要求进行维护的原因多有三种类型 1 改正在特定的使用条件下暴露出来的一些潜在程序错误或设计缺陷 2 因在软件使用过程中数据环境发生变化 例如一个事务处理代码发生改变 或处理环境发生变化 例如安装了新的硬件或操作系统 需要修改软件以适应这种变化 3 用户和数据处理人员在使用时常提出改进现有功能 增加新的功能 以及改善总体性能的要求 为满足这些要求 就需要修改软件把这些要求纳入到软件之中 11 1软件维护的种类 1 校正性维护 Correctivemaintenance 为了识别和纠正软件错误 改正软件性能上的缺陷 排除实施中的误使用 应当进行的诊断和改正错误的过程 就叫做校正性维护 11 1软件维护的种类 2 适应性维护 Adaptivemaintenance 随着计算机的飞速发展 外部环境 新的硬 软件配置 或数据环境 数据库 数据格式 数据输入 输出方式 数据存储介质 可能发生变化 为了使软件适应这种变化 而去修改软件的过程就叫做适应性维护 3 完善性维护 Perfectivemaintenance 在软件的使用过程中 用户往往会对软件提出新的功能与性能要求 为了满足这些要求 需要修改或再开发软件 以扩充软件功能 增强软件性能 改进加工效率 提高软件的可维护性 这种情况下 进行的维护活动叫做完善性维护 11 1软件维护的种类 4 预防性维护 Preventivemaintenance 除了以上三类维护之外 还有一类维护活动 叫做预防性维护 这是为了提高软件的可维护性 可靠性等 为以后进一步改进软件打下良好基础 11 1软件维护的种类 注意 在维护阶段的最初一 二年 校正性维护的工作量较大 随着错误发现率急剧降低 并趋于稳定 就进入了正常使用期 然而 由于改造的要求 适应性维护和完善性维护的工作量逐步增加 在这种维护过程中又会引入新的错误 从而加重了维护的工作量 实践表明 在几种维护活动中 完善性维护所占的比重最大 即大部分维护工作是改变和加强软件 而不是纠错 用户要求扩充 加强软件功能 性能的维护活动约占整个维护工作的50 11 1软件维护的种类 11 2软件维护的特点 11 2 1软件维护面临的困难统计资料表明 有代表性的软件开发组织用于校正性维护 适应性维护 完善性维护及预防性维护的费用占其开发总金额的70 至80 很多软件机构被束缚在维护工作上 这是软件维护所带来的无形支出 11 2 2产生软件维护问题的根源 软件维护中出现的大多数问题 究其根源往往是由于软件开发计划及开发方法方面的缺陷造成的 软件维护就是弥补软件设计和开发过程中的缺陷 客户可能会无休止地要求 维修 那些新出来的问题或要求改进 修改的成本很高任何考虑不周到的变动都可能造成软件系统不能正常运转 甚至给软件系统造成不可恢复的灾难 11 2 3非结构化维护 无说明或者文档资料太少由于没有采用定义良好的软件项目管理过程来开发软件 软件项目管理的缺陷导致的叫 非结构化维护 这会使软件维护付出较高的代价 11 2 4结构化维护 存在完整的软件系列文档 那么维护任务就从分析设计文件开始 确定软件的重要结构特性 功能特性和接口特性 确定所要求的修改或校正可能产生的影响 并且计划采用何种维护处理方法 修改设计并进行复审 编制出新的源程序 利用文档中的信息进行回归测试 然后重新交付软件 这种维护过程就叫做 结构化维护 11 3软件维护的实施 为了有效地进行软件维护 应事先就开始做组织工作 首先需要建立维护的机构 申明提出维护申请报告的过程及评价的过程 为每一个维护申请规定标准的处理步骤 还必须建立维护活动的登记制度以及规定评价和评审的标准 11 3 2软件维护申请报告 软件维护申请应按规定的方式提出 软件维护组织通常提供维护申请报告 MRR MaintenanceRequestReport 或称软件问题报告 由申请维护的用户填写 11 3 1维护机构 11 3 1维护机构 维护申请提交给一个维护管理员 他把申请交给某个系统监督员去评价 系统监督员是一位技术人员 他必须熟悉产品程序的某一部分 一旦做出评价 由修改负责人确定如何进行修改 维护人员对程序进行修改的过程中 由配置管理员严格把关 控制修改的范围 对软件配置进行审计 维护管理员 系统监督员 修改负责人等 均代表维护工作的某个职责范围 修改负责人 维护管理员可以是指定的某个人 也可以是一个包括管理人员 高级技术人员在内的小组 系统监督员可以有其他职责 但应具体分管某一个软件包 11 3 2软件维护申请报告 软件维护申请应按规定的方式提出 软件维护组织通常提供维护申请报告 MRR MaintenanceRequestReport 或称软件问题报告 由申请维护的用户填写 维护申请报告是由软件组织外部提交的文档 它是计划维护工作的基础 软件组织内部应相应地做出软件修改报告 SCR SoftwareChangeReport 指明 1 所需修改变动的性质 2 申请修改的优先级 3 为满足某个维护申请报告 所需的工作量 4 预计修改后的状况 软件修改报告应提交修改负责人 经批准后才能开始进一步安排维护工作 11 3 3软件维护工作流程 11 3 4维护档案记录 为了估计软件维护的有效程度 确定软件产品的质量 同时确定维护的实际开销 需要在维护的过程中做好维护档案记录 其内容包括程序名称 源程序语句条数 机器代码指令条数 所用的程序设计语言 程序安装的日期 程序安装后的运行次数 与程序安装后运行次数有关的处理故障次数 程序改变的层次及名称 修改程序所增加的源程序语句条数 修改程序所减少的源程序语句条数 每次修改所付出的 人时 数 修改程序的日期 软件维护人员的姓名 维护申请报告的名称 维护类型 维护开始时间和维护结束时间 花费在维护上的累计 人时 数 维护工作的净收益等 11 3 5维护评价 每次程序运行时的平均出错次数 花费在每类维护上的总 人时 数 每个程序 每种语言 每种维护类型的程序平均修改次数 因为维护 增加或删除每个源程序语句所花费的平均 人时 数 用于每种语言的平均 人时 数 维护申请报告的平均处理时间 各类维护申请的百分比 这七种度量值提供了定量的数据 据此可对开发技术 语言选择 维护工作计划 资源分配以及其他许多方面做出判定 因此 这些数据可以用来评价维护工作 11 4软件的可维护性 11 4 1影响可维护性的因素软件的可维护性可以简单定义为 纠正软件系统出现的错误和缺陷 以满足新的要求 能够被理解 被校正 被修改或被改善的难易程度 可维护性不但与采用的分析设计方法和开发人员的技术熟练程度有关 更重要的是与软件项目的管理技术关系密切 软件的可维护性成为软件开发阶段各个时期的关键目标 11 4 1影响可维护性的因素 除了与开发方法有关的因素之外 以下因素会对可维护性有重要影响 1 软件设计人员是否受到严格的规范化工作培训 2 是否采用主流的编程语言 3 是否采用主流的操作系统 4 是否采用标准化的文档资料结构和文档形成机制 5 是否保存规范化的测试资料 11 4 2软件可维护性的度量 1 可理解性2 可靠性可靠性 度量的标准主要有 平均失效间隔时间MTTF MeanTimeToFailure 平均修复时间MTTR MeanTimeToRepairerror 有效性A 1 根据程序错误统计数字 进行可靠性预测 2 根据程序复杂性 预测软件可靠性 11 4 2软件可维护性的度量 3 可测试性4 可修改性5 可移植性6 效率7 可使用性8 间接度量可维护性的方法 11 4 2软件可维护性的度量 8 间接度量可维护性的方法 1 了解问题的时间 2 行政管理拖延的时间 3 收集维护工具的时间 4 分析问题的时间 5 改变规格说明的时间 6 具体的改错或修改的时间 7 局部测试时间 8 整体测试时间 9 维护重审时间 10 总体恢复时间 11 4 3提高可维护性的方法 1 建立明确的软件质量目标和优先级一个可维护的程序应是可理解的 可靠的 可测试的 可修改的 可移植的 效率高的 可使用的 尽管可维护性要求每 种质量特性都要得到满足 但它们的相对重要性应随程序的用途及计算环境的不同而不同 所以当对程序的质量特性 在提出目标的同时还必须规定它们的优先级 2 使用提高软件质量的技术和工具 1 模块化和结构化程序设计 2 使用结构化程序设计技术 提高现有系统的可维护性 11 4 3提高可维护性的方法 3 进行明确的质量保证审查4 验收检查验收检查是一个特殊的检查点的检查 是交付使用前的最后一次检查 是软件投入运行之前保证可维护性的最后机会 1 需求和规范标准 需求应当以可测试的术语进行书写 排列优先次序和定义 2 设计标准 程序应设计成分层的模块结构 每个模块应完成唯一的功能 并达 3 源代码标准尽可能使用最高级的程序设计语言 且只使用语言的标准版本 4 文档标准 文档中应说明程序的输入 输出 11 4 3提高可维护性的方法 5 周期性地维护审查6 选择可维护的程序设计语言7 健全程序的文档好的文档是建立可维护性的基本条件 它的作用和意义有三点 1 文档好的程序比没有文档的程序容易操作 因为它增加了程序的可读性和可使用性 但不正确的文档比根本没有文档要坏得多 2 好的文档意味着简洁 风格一致且易于更新 3 程序应当成为其自身的文档 也就是说 在程序中应插入注释 以提高程序的可理解性 并缩进 空行等明显的视觉组织来突出程序的控制结构 如果程序越长越复杂 则它对文档的需要就越迫切 11 4 3提高可维护性的方法 在软件维护阶段 要利用历史文档历史文档有三种 系统开发日志 运行记录 系统维护日志 记录在维护阶段对系统修改和相关信息 11 5软件维护的副作用 软件维护可能产生副作用 这里副作用是指由于修改软件而造成的错误或发生其他不希望发生的情况 修改的内容不同 副作用也不一样 1 修改软件源程序的副作用 最危险的副作用是修改软件源程序而产生的 每当对一个复杂的逻辑过程做了一处修改 出错的可能性就增大了 下列对源程序的修改更易产生错误 1 改变一个子程序 函数 变量定义 2 为改进运行性能所作的修改 3 改变了逻辑运算过程 4