任务:确定配置管理(CM)策略
此任务描述了如何开发包含配置识别实践、设立基线实践、归档实践和配置报告需求在内的 CM 策略。
用途

此任务的目的是建立项目配置管理策略,用于监视和保护项目资产,并执行软件开发实践。项目策略应该增进团队成员间的交流,并将在集成工作中遇到的问题减到最少。 

关系
角色主要: 其他: 辅助:
输入必需: 可选: 外部:
输出
步骤
定义配置识别实践
目的:识别工作产品并将其存储在安全的存储库中 
工具向导:使用 Rational ClearCase 创建基线 

配置识别是配置管理的核心组成部分,它被 IEEE 定义为“配置管理元素,包括:选择系统的配置项,并将它们的功能特征和物理特征记录在技术文档中”。就软件配置管理而言,配置识别意味着能快速方便地查找和识别任何项目工作产品的正确版本。无效的配置识别系统的负面影响是用时间的浪费和质量的下降来衡量的。

标签用来标识工作产品的特定版本。组成某个版本的子系统的工作产品集合可以用特定版本和标签来进行整体和单个标识。因此,标签在复用或引用版本化工作产品的原始集合时很有用。

以下是可以用于在产品目录结构中标注路径和工作产品的推荐产品级工作产品标注约定。

<SYSTEM>[<A>]_[<SUBSYSTEM>]_[<A>]_[R|A|B]<X>[.<Y>.<Z>][.BL<#>]

<SYSTEM> 标识系统

<A> 代表三个字母的首字母缩写(TLA!)。它用于代表在创建系统时使用的各类工作产品。例如:

PLN  项目计划 
REQ  需求文件 
USC  用例 
MOD  模型文件 
SRC  源代码文件 
INT  公共接口 
TST  测试脚本和结果 
DOC  文档(用户、发行说明) 
BIN  可执行文件 

<SUBSYSTEM> 标识每个子系统

<A> 代表在创建子系统时使用的各类工作产品的三个字母的首字母缩写。与上表一致。

R|A|B  代表发行版、alpha 或 beta 版 
<X>  整数,代表主发行版(例如 1) 
<Y>  整数(可选),代表次发行版 
<Z>  整数(可选),代表其他发行版(补丁、端口等) 
BL  代表基本级别(内部发行版) 
整数,用于内部发行版 

下面是一些示例:

T2K_R1.0  Thorn 2000 系统的 R1 版 
T2K_GUI_R2.0.BL5  GUI 系统的内部发行版,计划在 R2 版中交付 
T2K_B1.1  Thorn 2000 系统的 Beta 1.1 版 
T2K_R2.0.BL16  thorn 2000 的内部系统基线 #16,计划用于创建 R2 版 
T2K_R1.0.5  Thorn 2000 的维护版 
定义设立基线实践

基线提供了稳定点和项目工作产品的快照。概念:设立基线描述了需要在项目生命周期的什么时候创建基线。该步骤提供对做法的进一步指导。

基线识别文件和目录版本的固定集合,并在给定的项目里程碑处创建。 可以为子系统创建基线,也可以为整个系统创建基线。基线应该根据上一个流程步骤(定义工作产品标注约定)中概述的方案进行识别。

需要在创建基线时进行区分的是您将创建的是:

  • 已经在一个或多个子系统中修改的文件和目录的“所有”版本的“子系统基线”。
  • 所有子系统中所有文件和目录的“单一”版本的“系统基线”。

作为一个通用指南,它将协助发行版管理,以便在主要和次要的项目里程碑处创建系统基线,并按需要或以更高的频率创建子系统基线。根据经验,如果子系统中有多达 30% 的元素发生了变更,就可以创建基线了。

定义归档实践

该步骤的目的是确保项目软件以及相关资产(主文档)得到备份、已编目并转移到指定的存储地点。归档文件在重用或灾难时刻显示它们的价值。这样,就需要定期执行归档,并在主要和次要里程碑处执行归档。

先前在流程步骤“定义工作产品标注约定”中描述的标注指南可以在创建归档标签时使用。但是,对于存储实际介质的地方可能需要其他信息。例如:

序列号  123456789 
卷  卷 1(共 3 卷) 
保险库文件  B5 
存储日期  1999 年 6 月 21 日 

所有与产品相关的信息都应该在数据库中进行维护以帮助发行和重用。

定义配置状态报告需求
用途 变更活动是项目状态和趋势的强有力的指示符。 该流程步骤的目的是让项目经理定义要报告哪些与产品相关的变更数据、由谁报告以及报告的频率是多少。 
子步骤:  
工具向导:  

配置状态报告(若使用)描述了创建“配置状态报告”的各种来源。

选择基于变更请求的报告 回到页首

在此处,您应该选择可以从提交到项目的变更请求中得出的报告。有很多有用的基于变更请求的报告。

在“帐龄”类别下,可根据以下条件,并按照一周或一月计算的变更请求的数量来请求报告:

  • 已提交
  • 已分配
  • 已解决
  • 优先级

按状态列出问题可以帮助确定项目离完成还有多远。例如,如果一批问题已经解决,那么项目离完成的时间就比一批问题还处于已提交状态要近了。

在“分发”类别下,可以要求报告回答下列类型的问题:

  • 谁在查找,什么类型的缺陷,在项目的哪个点?
  • 问题指定给谁?
  • 给定工程师有多少问题待解决?
  • 查找到的缺陷有多严重?
  • 问题是在流程的哪一步造成的(根源)?
  • 问题什么时候可以得到解决?
  • 有多少缺陷?
  • 这些缺陷有多严重?

这些标准可以帮助分析工作负载、谁正在处理最关键的问题以及问题能够多快得到解决。

在“趋势”类别下,可以要求报告回答下列类型的问题:

  • 这一天、这一周或这个月有多少缺陷尚待解决?
  • 这一天、这一周或这个月解决了多少缺陷?

这些数据在评估修复比例时很有用,可以指示工程的效率。

定义报告频率 回到页首

确保能够按正确的频率接收报告,以便对决策提供有意义的输入信息。可以按下列条件请求报告:

  • 每天 - 按照这个频率要求报告似乎不太可能
  • 每周 - 趋势、分发和计数报告、构建报告
  • 每月 - 趋势、分发和计数报告、构建报告
  • 按迭代 - 趋势、分发和计数报告、构建报告、版本说明
  • 按阶段 - 趋势、分发和计数报告、审计、构建报告、版本说明
  • 项目结束时 - 趋势、分发和计数报告、审计、构建报告、版本说明


属性
多次出现
事件驱动
正在进行
可选
已计划
可重复
更多信息