第6章软件维护和再工程.pptVIP

第6章软件维护与再工程;6.1 软件维护的概念; Lientz和Swanson(1980)对维护的工作量做过调查，如图所示。Nosek和Palvia(1990)在十年后给出的数据与此相似。 适应性维护和增强 性维护占了绝大部分工 作量。维护是系统开发 过程的自然延续，同样 也涉及到需求描述、设 计、实现和测试活动。 ;2、维护的成本 维护成本和开发成本的比例在不同的应用域中是不同的。Guimaraes(1983)的研究表明，对于业务应用系统，维护成本和系统开发成本大体相等。对于嵌入式实时系统，维??费用是开发成本的四倍以上。 带来高维护费用的关键因素： ? 人员的不稳定 ? 合同责任 ? 维护人员技术水平 ? 系统结构衰退 遗留系统的结构受到频繁变更的破坏；没有使用现代的软件工程技术开发；文档不全、不一致；没有采用配置管理，系统变更时在寻找系统构件的合适版本上浪费时间。 ; Belady和Lehman提出了一个计算维护工作量的模型： M＝p＋K×e(c－ d) 其中 M：软件维护所有的工作量； p：生产性工作量（分析、设计、编码及测试）； K：经验常数； c：复杂程度； d：维护人员对软件的熟悉程度。 该模型描述了影响维护的诸多因素中重要的关系。如果一个系统开发没有遵循软件工程原则，软件结构不好，c的值就会很高，再加上维护人员对软件的不熟悉，d的值很低。结果是，维护的成本呈指数级的增长。 ; 如何降低软件维护的费用？ （1）从开发阶段的一开始就按质量标准构建系统，给予“可维护性”属性以足够的重视，这样可以使系统的整个生命周期成本减少。下图说明了这个问题。系统1在开发成本中多投入$25000，用于提高系统的可维护性，结果在整个生命周期中节省了$100 000的维护成本。 ; （2）采用演化式的系统开发模型（如增量、螺旋），建立能结合新需求而演化和变更的系统。 （3）实施软件再工程，改善系统结构，提高可维护性。 ;6.2 软件维护活动; 该图说明了当请求进行一些变更时要执行的活动，底部带标注的箭头代表提供的度量信息，管理人员利用这些信息决定什么时候和怎样进行变动。 维护活动的一般过程： （1）变更分析 分析各种变更带来的的负面影响： 产生不正确或不完整的补丁软件、结构很差的设计与编码、构件不标准等等。 这些负面影响使软件复杂性增加，更不易理解。因此对变更的成本、影响要进行分析。 （2）理解变更，规划新版本 根据变更的类型（缺陷修正、平台适应或系统增强），决定哪些变更在下一个版本中完成。 ; （3）实现变更 分析系统变更的需求（如有必要，可对提出的变更建立原型），对系统构件重新设计，编码、测试。软件开发中重要的配置管理思想在这里同样适用。 对于紧急变更，保证更快速度完成比保证变更过程规范化更重要。 （4）影响分析 维护活动中改动的是需求、设计与代码构件、测试用例以及文档等工作产品。一个工作产品的质量可能影响到其他工作产品， Pfleeger（1990）提出必须建立并跟踪工作产品之间的关系，帮助我们评估一个构件的变更对所有其他构件的影响。下图展示了工作产品之间的关系及可追踪性：; ; 其中： 每个矩形框内的结点：表示为该阶段产生的工作产品或构件。 构件及之间的实线箭头：构成了度量产品的垂直跟踪图。 虚线箭头连接的图：构成了系统的水平跟踪图，代表了对变更的一个过程的度量。 在某一阶段内（矩形框内）的产品变更前后分别对以下度量指标求值： ? 结点总数 ? 指向一个结点的边数（该结点的入度） ? 一个结点发