软件维护PPT课件

9.3.5 维护评价
一般来说，可以从以下七个方面来评价维护工 作： （1）每次程序运行时的平均出错次数； （2）用于每一类维护活动的总“人时”数； （3）每个程序、每种语言、每种维护类型所做 的平均修改数； （4）维护过程中，增加或删除每条源程序语句 花费的平均“人时”数； （5）用于每种语言的平均“人时”数； （6）一张维护申请报告的平均处理时间； （7）各类维护类型所占的百分比。
计划途径 ？ 修改设计 重新编码 重新编码
复查
复查
交付使用
9.2.2 维护成本
无形的维护成本： （1）一些看起来是合理的改错或修改的要求不能及时 满足，使得用户不满意； （2）维护时产生的改动，可能会带来新的潜伏的故障， 从而降低了软件的整体质量； （3）当必须把软件开发人员抽调去进行维护工作时， 将在开发过程中造成混乱。
9.3 软件维护过程
9.3.1 维护机构 9.3.2 维护申请报告 9.3.3 维护的工作流程 9.3.4 维护记录 9.3.5 维护评价
退出
9.3.1 维护机构
维护要求 维护管理员 修改负责人
系统管理员
来自百度文库
„
„
„
软件系统
维护管理员 负责接受维护申 请，然后把维护 申请交给某个系 统管理员去评价。 系统管理员是一 名技术人员，他 必须熟悉软件产 品的某一部分。 系统管理员对维 护申请做出评价， 然后交与修改负 责人确定如何进 行修改。
9.3.4 维护记录
对于维护记录中的内容， Swanson 给出了下述 的项目表： （1）程序名称； （2）源程序语句条数； （3）机器代码指令条数； （4）使用的程序设计语言； （5）程序的安装日期； （6）程序安装后的运行次数； （7）与程序安装后运行次数有关的处理故障的 次数；
（8）程序修改的层次和名称； （9）由于程序修改而增加的源程序语句条数； （10）由于程序修改而删除的源程序语句条数； （11）每项修改所付出的“人时”数； （12）程序修改的日期； （13）软件维护人员的姓名； （14）维护申请报告的名称； （15）维护类型； （16）维护开始时间和维护结束时间； （17）用于维护的累计“人时”数； （18）维护工作的净收益。
9.3.2 维护申请报告
维护申请报告是由软件组织外部提交的文档， 它是计划维护活动的基础。软件组织内部应依此制 定相应的软件修改报告，这个报告包括以下内容： （1）为满足某个维护申请要求所需的工作量； （2）所需修改变动的性质； （3）申请修改的优先级； （4）与修改有关的事后数据。 软件修改报告应提交修改负责人进行审核批准， 以便进行下一步工作。
9.2.3 维护的问题
（1）理解他人编写的程序一般都有一定的困难性。 （2）软件配置的文档严重不足甚至没有，或者没有合 格的文档。 （3）当需要对软件进行维护时，由于软件人员经常流 动，维护阶段持续的时间又很长，所以一般不能指望由原 来的开发人员来完成或提供软件的解释。 （4）绝大多数软件在设计时没有考虑到将来的修改问 题。 （5）软件维护可以说是一项毫无吸引力的工作。之所 以形成这样一种观念，一方面是因为软件维护工作量大， 看不到什么“成果”，更主要的原因是因为维护工作难度 大，又经常遭受挫折。
9.4 软件可维护性
9.4.1 软件可维护性的度量 9.4.2 提高软件可维护性的方法 退出
9.4.1 软件可维护性的度量
可以从以下四个方面来度是软件的可维护性： 1．可理解性 2．可测试性 3．可修改性 4．可移植性
9.4.2 提高软件可维护性的方法
1．建立明确的软件质量标准 2．利用先进的软件技术和工具 3．建立明确的质量保证制度 4．选择可维护的程序设计语言 5．改进软件的文档
9.3.3 维护的工作流程
改正性 维护要求 确定类型 不严重 安排改正 完善性 或适应性 性维护 人员安排 评价错误 严重程度 严重 开始 问题分析
维护任务 评价 优先次序 低 错误改正目录 高 人员安排 开始分析 开发目录 复审 修改后的软件
通过后交付使用的软件
无论是哪一种类型的维护，都要进行以下工作： （1）修改软件设计； （2）设计复审； （3）对源代码的必要修改； （4）单元测试； （5）集成测试，包括回归测试； （6）验收测试； （7）软件配置复审。 在每次软件维护任务完成后，需要进行必要的情况评审。 这种评审是对以下问题的一个小结： （1）在当前情况下，设计、编码、测试中的哪些方面 能够改进？ （2）哪些维护资源是应该有而实际上却没有的？ （3）工作中的主要和次要的障碍是什么？ （4）要求的维护类型中有预防性维护吗？
用于软件维护的工作量可以分为两部分：一部分用于 生产性活动，另一部分用于非生产性活动。下面的表达 式是由Belady和Lehman提出的维护工作量的计算模型： M＝p＋K×e(c – d) M：维护中消耗的总工作量； p：生产性工作量； K：经验常数； c：复杂程度； d：维护人员对软件的熟悉程度。 通过这个模型可以看出，如果使用了不好的软件开发 方法，参加维护的人员都不是原来开发的人员，那么维 护工作量（及成本）将按指数级增加。
第九章 软件维护
9.1 软件维护的概念
9.2 软件维护的特点
9.3 软件维护过程 9.4 软件可维护性 9.5 软件维护的副作用
退出
9.1 软件维护的概念
9.1.1 软件维护的种类
9.1.2 影响维护工作量的因素 退出
9.1.1 软件维护的种类
一般来说，要求进行维护的原因大致有以下几 种： （1）改正程序中的错误和缺陷。 （2）改进设计以适应新的软、硬件环境。 （3）增加新的应用范围。 综合以上几种要求进行维护的原因，我们可以 把软件维护分为以下几类： 1．改正性维护 2．适应性维护 3．完善性维护 4．预防性维护
9.1.2 影响维护工作量的因素
1．系统的规模 2．系统的年龄 3．系统的结构 4．程序设计语言 5．文档的质量
9. 2 软件维护的特点
9.2.1 软件工程与软件维护的关系 9.2.2 维护成本 9.2.3 维护的成本
退出
9.2.1 软件工程与软件维护的关系
维护要求
软件 配置 评价设计
代码
评价代码