软件维护的分类课件.ppt
- 【下载声明】
1. 本站全部试题类文档,若标题没写含答案,则无答案;标题注明含答案的文档,主观题也可能无答案。请谨慎下单,一旦售出,不予退换。
2. 本站全部PPT文档均不含视频和音频,PPT中出现的音频或视频标识(或文字)仅表示流程,实际无音频或视频文件。请谨慎下单,一旦售出,不予退换。
3. 本页资料《软件维护的分类课件.ppt》由用户(ziliao2023)主动上传,其收益全归该用户。163文库仅提供信息存储空间,仅对该用户上传内容的表现方式做保护处理,对上传内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(点击联系客服),我们立即给予删除!
4. 请根据预览情况,自愿下载本文。本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
5. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007及以上版本和PDF阅读器,压缩文件请下载最新的WinRAR软件解压。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 维护 分类 课件
- 资源描述:
-
1、西安交通大学 刘海岩1l软件维护的概念l软件维护的活动l软件的可维护性l软件再工程西安交通大学 刘海岩2 当软件系统在实际环境被用户使用时,软件开发宣告结束。但软件总是要变化的,在软件交付使用后修改软件的过程称为软件维护。软件维护一般不包括重大的体系结构的改变,变更的实现方法一般是修改已有的系统构件以及在必要的地方添加新构件到系统中。1、软件维护的分类、软件维护的分类 改正性维护:修改软件缺陷。适应性维护:适应变更的操作环境(硬件、操作系统 平台、其他支持软件)。增强性维护:系统需求改变(机构因素、业务改变)。西安交通大学 刘海岩3 Lientz和Swanson(1980)对维护的工作量做过调
2、查,如图所示。Nosek和Palvia(1990)在十年后给出的数据与此相似。适应性维护和增强 性维护占了绝大部分工 作量。维护是系统开发 过程的自然延续,同样 也涉及到需求描述、设 计、实现和测试活动。西安交通大学 刘海岩42、维护的成本、维护的成本 维护成本和开发成本的比例在不同的应用域中是不同的。Guimaraes(1983)的研究表明,对于业务应用系统,维护成本和系统开发成本大体相等。对于嵌入式实时系统,维护费用是开发成本的四倍以上。带来高维护费用的关键因素:人员的不稳定 合同责任 维护人员技术水平 系统结构衰退 遗留系统的结构受到频繁变更的破坏;没有使用现代的软件工程技术开发;文档不
3、全、不一致;没有采用配置管理,系统变更时在寻找系统构件的合适版本上浪费时间。西安交通大学 刘海岩5 Belady和Lehman提出了一个计算维护工作量的模型:MpKe(c d)其中 M:软件维护所有的工作量;p:生产性工作量(分析、设计、编码及测试);K:经验常数;c:复杂程度;d:维护人员对软件的熟悉程度。该模型描述了影响维护的诸多因素中重要的关系。如果一个系统开发没有遵循软件工程原则,软件结构不好,c的值就会很高,再加上维护人员对软件的不熟悉,d的值很低。结果是,维护的成本呈指数级的增长。西安交通大学 刘海岩6 如何降低软件维护的费用?如何降低软件维护的费用?(1)从开发阶段的一开始就按质
4、量标准构建系统,给予“可维护性”属性以足够的重视,这样可以使系统的整个生命周期成本减少。下图说明了这个问题。系统1在开发成本中多投入$25000,用于提高系统的可维护性,结果在整个生命周期中节省了$100 000的维护成本。西安交通大学 刘海岩7 (2)采用演化式的系统开发模型(如增量、螺旋),建立能结合新需求而演化和变更的系统。(3)实施软件再工程,改善系统结构,提高可维护性。西安交通大学 刘海岩8 Pfleeger和Bohner(1990)提出了软件维护的一种模型,其中包含了度量的反馈,见下图:西安交通大学 刘海岩9 该图说明了当要求进行一项变动时要执行的活动,底部带标注的箭头代表提供的度
5、量信息,管理人员利用这些信息决定什么时候和怎样进行变动。维护活动:维护活动:(1)变更分析 各种变更带来的的负面影响:产生不正确或不完整的补丁软件、结构很差的设计与编码、构件不标准等等。这些负面影响使软件复杂性增加,更不易理解。因此对变更的成本、影响要进行分析。(2)理解变更,规划新版本 根据变更的类型(缺陷修正、适应性调整或增加新功能),决定哪些变更在下一个版本中完成。西安交通大学 刘海岩10 (3)实现变更 分析系统变更的需求(如有必要,可对提出的变更建立原型),对系统构件重新设计,编码、测试。软件开发中重要的配置管理思想在这里同样适用。对于紧急变更,保证更快速度完成比保证变更过程规范化更
6、重要。(4)后果分析 维护活动中改动的是需求、设计与代码构件、测试用例以及文档等工作产品。一个工作产品的质量可能影响到其他工作产品,Pfleeger(1990)提出必须建立并跟踪工作产品之间的关系,帮助我们评估一个构件的变更对所有其他构件的影响。下图展示了工作产品之间的关系及可追踪性:西安交通大学 刘海岩11R1R2R3RiD1D2D3Dj.水平追踪连接水平追踪连接C1C2C3Ck.T1T2T3Tn.垂直追踪连接垂直追踪连接需求需求设计设计代码代码测试测试工作产品的追踪图工作产品的追踪图西安交通大学 刘海岩12 其中:每个矩形框内的结点表示为该阶段产生的工作产品或构件。构件及之间的实线箭头构成
7、了度量产品度量产品的垂直跟踪图的垂直跟踪图。某一阶段内(矩形框内),在产品变动前后分别对以下度量指标求值:结点总数、指向一个结点的边数(该结点的入度)、一个结点发出的边数(出度)、环路数。Pfleeger提出计算最小路径集,如果变动后覆盖的路径增加,或者结点的入度、出度增加,则系统会更复杂、更难于维护。利用此信息,维护组可能决定用另一种方式实现或者取消该变动。虚线箭头连接的图构成了系统的水平跟踪图水平跟踪图,代表了对变动的一个过程的度量过程的度量。每一对工作产品:需求产品与设计产品,设计产品与代码产品,代码产品与测试用例,在两者之间形成关系子图,度量规模和复杂性关系,从而得出负面影响。还可浏览
8、整个水平跟踪图,了解变动后总的可追踪性变得更复杂还是简单了。西安交通大学 刘海岩13 软件的可维护性、可靠性和可用性是衡量软件质量的几个主要特性,是用户最关心的几个问题。软件可维护性可定性地定义为:维护人员理解、改正、改动和改进这个软件的难易程度。1 1、用于衡量可维护性的软件特性、用于衡量可维护性的软件特性:可用下面 7 7个质量特性来衡量:可理解性、可测试性、可修改性、可靠性、可移植性、可理解性、可测试性、可修改性、可靠性、可移植性、可使用性可使用性和效率效率。对于不同类型的维护,这7种特性的侧重点也不相同。要将这些质量要求贯彻到各开发阶段的各步骤中。软件的可维护性是产品投入运行以前各阶段
展开阅读全文