2003年10月17日星期五（第五课）

2、软件配置管理计划

――项目开始制定，作为软件开发计划SDP的一部分

――国家标准GB/T /2505－90 计算机软件配置管理计划中的主要内容

1） 负责软件配置管理的组织及其任务、职责及其有关接口的控制 2） 软件配置管理活动

? 配置标识

? 配置控制（即变更控制） ? 配置状态记录和报告 ? 配置审核及其评审

3） 配置管理采用的工具、技术和方法

4） 附：软件配置管理计划示例及其配置管理报表示例

3、 软件配置标识（Configuration Identification）

――确定配置项（Configuration Item）

? 在软件生存期中需要管理起来的（或称需要受控的）软件项

（图2软件配置项：见课本，5个大圆圈，中间是“目标代码”）

? 配置项的多少因项目而异，项目大、负责、其数量可达数百、以至上千 ? 配置项分类

1） 技术性：规格说明，源代码清单、测试用例；非技术性（管理性）：计划、

报告等

2） 组织内或项目开发的；外购的

···（表2软件配置项清单：见课本） ――指定命名规则

? 原则

1） 唯一性 2） 可追溯性

? 树状层次式命名规则

（图3 树状结构命名示例）

4、 变更管理（Change Managemnet）

1） 配置数据库

――作用

? 记录与配置相关的信息 ? 评价系统变更的后果 ? 提供配置管理信息 ――三类库

? 开发库 Development Library

a、 专供开发人员使用

b、 库中信息可能频繁修改、更动 c、 控制宽松

? 受控库 Controlled Library

d、 存放开发阶段结束时的工作后果

e、 也称软件配置管理库

? 产品库 Product Library

f、 存放系统测试后的最终产品 g、 等待交付

――典型的数据库查询问题

1）哪些客户已提取了某个特定的系统版本 运行一个给定的系统版本需要什么硬件和操作系统 一个系统已生长了多少个版本，核实生成的

若某个特定的组建变更了，回影响到系统的哪些版本 一个特定的版本有那几个变更请求是最为重要的 一个特定的版本有多少已报告的错误

2） 基线与变更控制

――开发中的变更不可能完全避免 ? 变更来源

A、 用户的需求变更 B、 开发人员对技术方案或设计细部的变更 C、 管理人员提出的方案，设计变更

? 变更的原因

D、 开发人员掌握了更多的信息 E、 对问题或方案有了更深刻的认识

? 变更管理的任务

F、 分析变更

G、 记录、追踪变更

H、 使变更在受控状态下进行

必要性、经济可行性、技术可行性 ――基线（BaseLine）

? 软件生存期开发阶段末尾的特定点，也成为里程碑（milestone）

（图4软件配置基线，见课本）

? 开发阶段末尾，已经过验证的开发成果，不应作任意变更，将其“冻结”起来 ? 三种常用的基线

（1） 功能基线

? 经过正式评审和批准的系统设计说明中对待开发软件提出的规格说

明

? 经过项目委托单位和项目承担单位双方签字同意的合同中规定的待

开发软件的规格说明 ? 由下级申请及上级同意，或直接上级下达的项目任务书中规定的待开

发软件的规格说明

（2） 分配基线

软件需求阶段结束时，经过正式评审和批准的软件需求规格说明SRS－Software Requirement

（3） 产品基线

软件集成……………………………

?

3） 变更控制

――变更请求：提出变更请求表 Change Request Form（CRF） 表3 变更控制表

项目名———— 变更请求人———— 日期———— 编号———— 要求的变更描述———— 变更分析员———— 分析日期———— 受影响模块———— 变更评估———— 变更优先性———— 变更实现———— 估计工作量———— CCB收到日期————

CCB决定———————————————————————— 变更实施负责人———— 变更日期———— 递交QA日期———— QA决定———— 递交CM日期————

表中：CCB是变更控制委员会 （Change Control Board） QA质量保证组 （Quality Assuranme） CM是配置管理组 （）

――变更管理过程 （表4） ――记录变更

A、 将CRF作为配置项在数据库中登录 B、 在变更了的模块代码上变更记录

（表5变更记录示例）

5、 版本管理和发行管理

1） 版本管理是对系统不同版本进行标识和跟踪的过程

――版本标识的目的是便于对版本进行检索和跟踪，显示各版本的关系

――个版本是软件系统的一个实例，在功能和性能上与其他版本有所差别，或是修

正了前一版本的不足

――有些版本在功能上是等价，但分别适用于不同的硬件配置 ――如果两个版本 2）

3） 版本标识――版本的命名规格

――

（图7 非线形版本顺序） ――符号命名版本标识 ? 不用V1.1.2形式，而用VI/DB Server表示一个在VMS操作系统上运行的数据

库服务器版本

?

――属性版本标识

? 好处：容易加入新版本、版本间关系容易保持…..

6、 配置审核（Configuration Audit）

1） 什么是配置审核

――为发现和解法配置标识、变更控制、版本控制查错，而开展的验证活动 ――例如，变更评审是针对每一变更检查一致性、遗漏和肯那嘎的副作用 2） 配置审核提出的问题

――已确定的变更完成了吗？有没有作任意附加的修改？ ――是否进行了正式的技术评审，以便评估技术的正确性？ ――是否遵循了软件工程标准？

――变更是否指明了日期、变更者信息？

――所作的变更是否遵循了软件配置管理规程？

――任一变更可能涉及到其他软件配置项，是否也相应作了变更？

7、 配置状态报告（Configuration Status Reporting）

1） 什么是配置状态报告

――配置状态报告（也称Status Accounting）的目的是及时、准确地给出软件配置项的当前状态，供相关人员了解，以加强 ――配置状态报告肯那嘎提供的信息包括 ? 但前做了哪些变更 ? 谁参加了这些变更 ? 何时做的变更

? 可能的影响范围是哪些

――报告可以定期提供，也可以放入联机数据库中 2） …. 3） ….

8、 软件配置管理工具

1） 手工实施软件配置管理存在的问题

――负责配置管理的人员对配置管理的理解、经验、坚定性都是制约因素 ――配置管理规程指定得应有适用性、可操作性、否则效果不佳 ――人员可能有失误，如疏忽、遗忘

――个别人对其可能不理解，甚至有抵触情绪、培训是十分必要的 ――人员流动可能有影响 2） 采用配置管理工具支持的好处

――排除了上述认为因素的影响，避免了人员主观失误或不坚定实施等现象 ――节省了人员管理的时间，但不能免除责任人的责任 ――项目开发中出现配置管理问题的机会少了 3） 采用配置管理工具需考虑的问题

――工具价格的付出

――工具使用的培训不可少

――工具的适用性（而不是多功能性）必须作为选购的条件 4） 市场上已有的配置管理工具 （P171）