当前位置:高等教育资讯网  >  中国高校课件下载中心  >  大学文库  >  浏览文档

西安交通大学软件学院:《面向对象的软件工程》 第六章 软件维护

资源类别:文库,文档格式:PPT,文档页数:26,文件大小:491KB,团购合买
第6章软件维护 一、软件维护的概念 二、软件维护的活动 三、软件的可维护性 四、软件再工程
点击下载完整版文档(PPT)

第6章软件维护 软件维护的概念 软件维护的活动 软件的可维护性 软件再工程 安交通大学刘海岩

西安交通大学 刘海岩 1 第6章 软件维护 ⚫ 软件维护的概念 ⚫ 软件维护的活动 ⚫ 软件的可维护性 ⚫ 软件再工程

61软件维护的概念 当软件系统在实际环境被用户使用时,软件开发宣告结 束。但软件总是要变化的,在软件交付使用后修改软件的过 程称为软件维护 软件维护一般不包括重大的体系结构的改变,变更的实 现方法一般是修改已有的系统构件以及在必要的地方添加新 构件到系统中 1、软件维护的分类 改正性维护:修改软件缺陷 适应性维护:适应变更的操作环境(硬件、操作系统 平台、其他支持软件) 增强性维护:系统需求改变(机构因素、业务改变)。 安交通大学刘海岩

西安交通大学 刘海岩 2 6.1 软件维护的概念 当软件系统在实际环境被用户使用时,软件开发宣告结 束。但软件总是要变化的,在软件交付使用后修改软件的过 程称为软件维护。 软件维护一般不包括重大的体系结构的改变,变更的实 现方法一般是修改已有的系统构件以及在必要的地方添加新 构件到系统中。 1、软件维护的分类 • 改正性维护:修改软件缺陷。 • 适应性维护:适应变更的操作环境(硬件、操作系统 平台、其他支持软件)。 • 增强性维护:系统需求改变(机构因素、业务改变)

Lientz和 Swanson(1980)对维护的工作量做过调查, 如图所示。Noek和 Pavia(190在十年后给出的数据与 此相似。 适应性维护和增强 性维护占了绝大部分工 缺陷修补 (17%) 作量。维护是系统开发 功能添加 过程的自然延续,同样 软件适应性 和修改(65%) (18%) 也涉及到需求描述、设 计、实现和测试活动 维护工作量分布 安交通大学刘海岩

西安交通大学 刘海岩 3 Lientz和Swanson(1980)对维护的工作量做过调查, 如图所示。Nosek和Palvia(1990)在十年后给出的数据与 此相似。 适应性维护和增强 性维护占了绝大部分工 作量。维护是系统开发 过程的自然延续,同样 也涉及到需求描述、设 计、实现和测试活动

2、维护的成本 维护成本和开发成本的比例在不同的应用域中是不 同的。 Guimaraes(1983)的研究表明,对于业务应用系统, 维护成本和系统开发成本大体相等。对于嵌入式实时系 统,维护费用是开发成本的四倍以上 带来高维护费用的关键因素: 人员的不稳定 合同责任 维护人员技术水平 系统结构衰退 遗留系统的结构受到频繁变更的破坏;没有使用现 代的软件工程技术开发;文档不全、不一致;没有采用 配置管理,系统变更时在寻找系统构件的合适版本上浪 费时间。 安交通大学刘海岩

西安交通大学 刘海岩 4 2、维护的成本 维护成本和开发成本的比例在不同的应用域中是不 同的。Guimaraes(1983)的研究表明,对于业务应用系统, 维护成本和系统开发成本大体相等。对于嵌入式实时系 统,维护费用是开发成本的四倍以上。 带来高维护费用的关键因素: • 人员的不稳定 • 合同责任 • 维护人员技术水平 • 系统结构衰退 遗留系统的结构受到频繁变更的破坏;没有使用现 代的软件工程技术开发;文档不全、不一致;没有采用 配置管理,系统变更时在寻找系统构件的合适版本上浪 费时间

Belady和 Lehman提出了一个计算维护工作量的模型: M=p+K×e-0 其中M:软件维护所有的工作量; p:生产性工作量(分析、设计、编码及测试) K:经验常数; c:复杂程度 d:维护人员对软件的熟悉程度。 该模型描述了影响维护的诸多因素中重要的关系 如果一个系统开发没有遵循软件工程原则,软件结构不 好,c的值就会很高,再加上维护人员对软件的不熟悉, d的值很低。结果是,维护的成本呈指数级的增长 安交通大学刘海岩

西安交通大学 刘海岩 5 Belady和Lehman提出了一个计算维护工作量的模型: M=p+K×e (c- d) 其中 M:软件维护所有的工作量; p:生产性工作量(分析、设计、编码及测试); K:经验常数; c:复杂程度; d:维护人员对软件的熟悉程度。 该模型描述了影响维护的诸多因素中重要的关系。 如果一个系统开发没有遵循软件工程原则,软件结构不 好,c的值就会很高,再加上维护人员对软件的不熟悉, d的值很低。结果是,维护的成本呈指数级的增长

如何降低软件维护的费用? (1)从开发阶段的一开始就按质量标准构建系统,给 予“可维护性”属性以足够的重视,这样可以使系统的 整个生命周期成本减少。下图说明了这个问题。系统1在 开发成本中多投入$25000,用于提高系统的可维护性, 结果在整个生命周期中节省了$100000的维护成本 系统1 系统2 0501001502002503035040045050千美元 □开发成本 □维护成本 开发和维护成本 安交通大学刘海岩

西安交通大学 刘海岩 6 如何降低软件维护的费用? (1)从开发阶段的一开始就按质量标准构建系统,给 予“可维护性”属性以足够的重视,这样可以使系统的 整个生命周期成本减少。下图说明了这个问题。系统1在 开发成本中多投入$25000,用于提高系统的可维护性, 结果在整个生命周期中节省了$100 000的维护成本

2)采用演化式的系统开发模型(如增量、螺 旋),建立能结合新需求而演化和变更的系统 (3)实施软件再工程,改善系统结构,提高可维 护性。 安交通大学刘海岩

西安交通大学 刘海岩 7 (2)采用演化式的系统开发模型(如增量、螺 旋),建立能结合新需求而演化和变更的系统。 (3)实施软件再工程,改善系统结构,提高可维 护性

6.2软件维护活动 Pfleeger和 Bohner((1990)提出了软件维护的一种模型, 其中包含了度量的反馈,见下图 预防性 适应性 改正性 完善性 管理软 新系统 件维护性 变动 请求 分析软件 理解 实现维 解释波 (再)测试受 变动后果N软件的变动 护变动 动效应 影响的软件 已有系统 影响范围 复杂性 适应性 稳定性 可测试性 可追踪性 模块性 致性 检测性 导向图 文档自描述 完整性 软件维护活动

西安交通大学 刘海岩 8 6.2 软件维护活动 Pfleeger和Bohner(1990)提出了软件维护的一种模型, 其中包含了度量的反馈,见下图:

该图说明了当要求进行一项变动时要执行的活动 底部带标注的箭头代表提供的度量信息,管理人员利 用这些信息决定什么时候和怎样进行变动 维护活动: 1)变更分析 各种变更带来的的负面影响 产生不正确或不完整的补丁软件、结构很差的设 计与编码、构件不标准等等。 这些负面影响使软件复杂性增加,更不易理解。 因此对变更的成本、影响要进行分析 (2)理解变更,规划新版本 根据变更的类型(缺陷修正、适应性调整或增加 新功能),决定哪些变更在下一个版本中完成。 安交通大学刘海岩

西安交通大学 刘海岩 9 该图说明了当要求进行一项变动时要执行的活动, 底部带标注的箭头代表提供的度量信息,管理人员利 用这些信息决定什么时候和怎样进行变动。 维护活动: (1)变更分析 各种变更带来的的负面影响: 产生不正确或不完整的补丁软件、结构很差的设 计与编码、构件不标准等等。 这些负面影响使软件复杂性增加,更不易理解。 因此对变更的成本、影响要进行分析。 (2)理解变更,规划新版本 根据变更的类型(缺陷修正、适应性调整或增加 新功能),决定哪些变更在下一个版本中完成

(3)实现变更 分析系统变更的需求(如有必要,可对提出的变 更建立原型),对系统构件重新设计,编码、测试 软件开发中重要的配置管理思想在这里同样适用 对于紧急变更,保证更快速度完成比保证变更过 程规范化更重要。 (4)后果分析 维护活动中改动的是需求、设计与代码构件、测 试用例以及文档等工作产品。一个工作产品的质量可 能影响到其他工作产品, Pfleeger(1990)提出必须建 立并跟踪工作产品之间的关系,帮助我们评估一个构 件的变更对所有其他构件的影响。下图展示了工作 品之间的关系及可追踪性: 安交通大学刘海岩

西安交通大学 刘海岩 10 (3)实现变更 分析系统变更的需求(如有必要,可对提出的变 更建立原型),对系统构件重新设计,编码、测试。 软件开发中重要的配置管理思想在这里同样适用。 对于紧急变更,保证更快速度完成比保证变更过 程规范化更重要。 (4)后果分析 维护活动中改动的是需求、设计与代码构件、测 试用例以及文档等工作产品。一个工作产品的质量可 能影响到其他工作产品, Pfleeger(1990)提出必须建 立并跟踪工作产品之间的关系,帮助我们评估一个构 件的变更对所有其他构件的影响。下图展示了工作产 品之间的关系及可追踪性:

点击下载完整版文档(PPT)VIP每日下载上限内不扣除下载券和下载次数;
按次数下载不扣除下载券;
24小时内重复下载只扣除一次;
顺序:VIP每日次数-->可用次数-->下载券;
共26页,试读已结束,阅读完整版请下载
相关文档

关于我们|帮助中心|下载说明|相关软件|意见反馈|联系我们

Copyright © 2008-现在 cucdc.com 高等教育资讯网 版权所有