软件维护的分类

软件维护的分类
预览:

(3)实施软件再工程,改善系统结构,提高可维 护性。

西安交通大学 刘海岩

7

6.2 软件维护活动
Pfleeger和Bohner(1990)提出了软件维护的一种模型, 其中包含了度量的反馈,见下图:

西安交通大学 刘海岩

8

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

西安交通大学 刘海岩

9

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

水平追踪连接
R1 R2 R3
. . .

垂直追踪连接
C1 C2 C3
. . .

D1 D2 D3
. . .

T1 T2 T3
. . .

Ri

Dj

Ck

Tn

需求

设计

代码

测试

工作产品的追踪图
西安交通大学 刘海岩 11

其中:每个矩形框内的结点表示为该阶段产生的工 作产品或构件。构件及之间的实线箭头构成了度量产品 的垂直跟踪图。某一阶段内(矩形框内),在产品变动 前后分别对以下度量指标求值: 结点总数、指向一个结点的边数(该结点的入度)、 一个结点发出的边数(出度)、环路数。 Pfleeger提出计算最小路径集,如果变动后覆盖的 路径增加,或者结点的入度、出度增加,则系统会更复 杂、更难于维护。利用此信息,维护组可能决定用另一 种方式实现或者取消该变动。 虚线箭头连接的图构成了系统的水平跟踪图,代表 了对变动的一个过程的度量。每一对工作产品:需求产 品与设计产品,设计产品与代码产品,代码产品与测试 用例,在两者之间形成关系子图,度量规模和复杂性关 系,从而得出负面影响。还可浏览整个水平跟踪图,了 解变动后总的可追踪性变得更复杂还是简单了。
西安交通大学 刘海岩

第2页/共26页 <上一页下一页>尾页

寻找更多 "软件维护的分类"