第8章 软件维护(new)

软件维护的过程－维护过程



对于非纠错性维护，则首先判断维护类型，对适 应性维护，按照评估后得到的优先级放入队列 对于改善性维护，则还要考虑是否采取行动，如 果接受申请，则同样按照评估后得到的优先级放 入队列，如果拒绝申请，则通知请求者，并说明 原因 对于工作安排队列中的任务，由修改负责人依次 从队列中取出任务，按照软件工程方法学规划、 组织、实施工程。
说明性文档不可缺少!
•别人的程序很难读懂 •文档与代码不一致 •开发人员往往不参加维护 •大多数软件在设计时没有考虑将来的修改
软件维护策略
1. 降低改正性维护成本的策略 显然，软件中包含的错误越少，改正性维护的 成本也就越低，但是，要生成100%可靠的软件通常 成本太高，并不一定合算。然而通过使用先进技术 仍然可以大大提高软件的可靠性，从而减少改正性 维护的需求。这些技术包括：数据库管理系统、软 件开发环境、程序自动生成系统、较高级(第四代) 的语言。以及新的开发方法、软件复用、防错程序 设计及周期性维护审查等
4.可维护性的度量
⑸ 可移植性(Portability) 是指程序被移到一个新环境的容易程度。 好程序的特征：结构好，不特别依赖于某一具体 的计算机或操作系统。 ⑹ 可使用性 用户观点出发，可使用性定义为程序方便、实 用、及易于使用的程度。一个可使用的程序应是 易于使用的、能允许用户出错和改变，并尽可能 不使用户陷入混乱状态的程序。

各种维护类型和维护工作量的比例
改正性 适应性 维 护 维护17％ 18-25% －21%
其它 维护 4%
维护占 70.8%
完善性维护 50%－66％
一般维护的工作量占生存周期70%以上，维护成本约为开 发成本的4倍(80 - 20 Rule)； 改正性维护占全部维护工作量的比率已大幅度下降
3、维护的问题
4.可维护性的度量
—— 软件度量学(Software Measurement)
软件可维护性可定性地定义为：维护人员理 解、改正、改动和改进这个软件的难易程度。 1、用于衡量可维护性的软件特性（7种）： 可理解性、可使用性、可测试性、可移植性、可 修改性、效率、可靠性 2、对于不同类型的维护，这七种特性的侧重点 也不相同。
（3）使用内部程序列表、外部文件及例行处理程序 包，可以为维护时修改程序提供方便。
软件维护策略
3. 降低完善性维护成本的策略 上述的减少前两类维护成本的策略，通常也能降 低完善性维护的成本。特别是数据库管理系统、程序 自动生成系统、软件开发环境、第四代语言和应用软 件包，可明显减少维护工作量。 此外，在需求分析过程中准确地预测用户将来可 能提出的需求，并且在设计时为将来可能提出的需求 预先做准备，显然是降低完善性维护成本的有力措施 。 在实际开发软件之前，建立软件的原型并让用户 试用，以进一步完善他们对软件的功能需求，也能显 著减少软件交付使用之后的完善性维护需求。
问题说明：(数据输入、错误 现象)不同类型的人员可以进行交 叉测评。 维护安排 按需求：各类人员只进行自身 类型的测评，如管理人员只能对管 理人员进行测评，教师只能测评教 维护类型 师。
维护要求及优先级： 维护时间 在测评之前必须修正，否则会造成 测评结果的不准确
环境
申请人：****** 申请评价结果：修正错误
软件的缺陷需要修复 软件在使用过程中，新的需求不断出现 商业环境在不断地变化 计算机软件、硬件环境升级，需要更新现有系统 软件的性能和可靠性需要改进

编程大师曾说过：“哪怕程序只 有三行长，总有一天你也不得不 对它进行维护。”
软件演化的处理策略

软件维护
—为了修改软件缺陷或增加新的功能而对软件的 组件进行变更 —不对软件的体系结构做重大改变

软件维护的概念－维护成本

维护工作量的模型
cd
M p Ke M：维护的总工作量 ； P：生产性工作量； K：经验常数； c：复杂程度； d：维护人员对软件的熟悉程度 上述模型表明，如果软件开发没有运用软件工程 方法学，而且原来的开发人员未能够参与到维护工 作之中，则维护工作量和费用将指数增加。
2、维护报告

维护人员对程序进行修改前要着重做好两个记录 维护申请报告 软件修改报告
⑴ 维护申请报告(Maintenance Request Form) 由用户填写的外部文件，对于改正性维护提供错误 情况说明（输入数据，错误清单等），或对适应性 或完善性维护提供修改需求说明书等。 一个维护申请被核准后，维护请求表就成为外 部文档，视作规划本次维护任务的依据。
n 资源用于开发新的软件。
3.维护过程
本质上是修改和压缩了的软件定义和开发过程。
1、建立维护组织(maintenance team)：
在维护活动开始之前就明确维护责任是十分必要
的，这样可以大大减少维护过程中可能出现的混乱。
变 化 授 权 人
任务评价
要 求 维 护
任务评价 客户要求
维护管理员
系 统 管 理 员
维护请求 其他 适应性 类型 完善性
类型
改正性 非常严重
严重性
并不严重
软 件 维 护 的 工 作 流
评估后按优先 级在队列排队 拒绝
评估后分类
采取的行动
“救火行动”,当 排在队列之首 接受
评估后按优先 级在队列排队
通知请求者 并说明原因
按优先级在 队列中排队
从维护请求队列之首取出一任务 按SE方法学规划、组织、实施工程 队列中还有维护请求吗？ y
√ 批准 评价负责人：***
⑵ 软件修改报告
与维护申请报告相应的内部文件，要求说明： ①所需修改变动的性质； ②申请修改的优先级； ③为满足某个维护申请报告，所需的工作量； ④预计修改后的状况。
软件修改报告(SCR)
软件名称
源程序名称 备份程序名称
相关文档列表
维护描述： 日期 修改内容 修改原因 特别说明

完善性维护（Perfective Maintenance）
扩充原有系统的功能，提高原有系统的性能，或 满足用户的实际需要。 例如: 在储蓄系统交付银行使用之后，增加扣除利息税 的功能； 缩短系统的响应时间，使之达到新的要求； 改变现有程序输出数据的格式，以方便用户； 在正在运行的软件中增加联机求助功能等，都是 完善性维护。
软件维护的分类
适应性维护（Adaptive Maintenance） 要使运行的软件能适应运行环境的变动而修改软 件的过程。 外部环境（新的硬、软件配臵） 数据环境（数据库、数据格式、数据输入/输出 方式、数据存储介质）

预防性维护（Preventive Maintenance ） 为了进一步改善软件的可靠性和易维护性，或 者为将来的维护奠定更好的基础而对软件进行修改。
软件维护请求报告
项目名称 网络测评系统
项目编号
预计维护的结果： 修正程序中的人员权限，使得每种类 型的人员只能进行自身类型的测评。 远程维护 √ 现场维护 软件： 纠错维护 √ 适应维护 完善维护 硬件： 系统设备 外部设备 自 ****年**月**日 至 *****年**月**日 共计 0.5 人月 拒绝
无论是哪一种类型的维护，都要进行以下工作： （1）修改软件设计； （2）设计复审； （3）对源代码的必要修改； （4）单元测试； （5）集成测试，包括回归测试； （6）验收测试； （7）软件配臵复审。
维护总结
在每次软件维护任务完成后进行情况评审，对以 下问题做一总结： (1) 在目前情况下，设计、编码、测试中的哪一 方面可以改进? (2) 哪些维护资源应该有但没有? (3) 工作中主要的或次要的障碍是什么? (4) 从维护申请的类型来看是否应当有预防性维 护? 情况评审对将来的维护工作如何进行会产生重要 的影响。

应该为每项维护工作都收集上述数据。可以利用这 些数据构成一个维护数据库。

软件维护记录
记录编号：eval_wh_012 计划编号：eval_wh_012 日期：****年**月**日 项目名称：网络测评系统 初始状态描述：不同类型的人员可以进行交叉测评。按需求：各类人员只进行自身 类型的测测评，如管理人员只能对管理人员进行测评，教师只能测评教师。 模块名称：测评控制管理 源程序行数：210 编程语言：PHP 失效次数：3 日期 **月**日 维护内容 查错，确定错误位臵 编号：evalobject_01 机器指令长度：25Kb 程序安装日期：****年**月**日 程序运行时间： 增/删/改 修改部分源程序 工作量 0.2个人月 维护人员 ****
增加代码行数 注释修改 修改开始日期
删除代码行数 相关文档修改 修改完成日期
修改代码行数
维护人
软件维护记录的保存
有效的保存维护记录是极端重要的。 保存维护记录的第一个问题就是那些数据值得保存？

程序标识、源语句数、机器指令数、使用的程序设 计语言、软件安装的日期、自安装以来软件运行的次 数、自安装以来软件失败的次数、程序变动的层次和 标识、因程序变动而增加的源语句数、因程序变动而 删除的源语句数、每个改动消耗的人时数、程序改动 的日期、软件工程师的名称、维护要求的标识、维护 类型、维护开始和完成的时间、用于维护的累计人时 数、与完成的维护相关联的纯收益。

软件再工程方法
—为了避免软件退化而对软件的一部分、甚至全 部重新设计、编码和测试，提高软件的可维护性、 可靠性等
软件维护的分类
纠错性维护（Corrective Maintenance ） 对在测试阶段未能发现的，在软件投入使用 所逐渐暴露出来的错误的测试、诊断、定位、纠错 以及验证、修改的回归测试过程。
第8章 软件维护
1
教学目标


理解:软件维护的基本概念 了解：软件维护过程 理解:软件可维护性、逆向工程和再生工程