配置管理流程
作者：龚云卿 撰写日期：2004年8月13日
规范配置管理活动，确保配置项正确地唯一标识并易于存取，保证基准配置项的更改受控，明确基线状态，在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。
对于不同类别的软件项目，配置管理的流程不同，可在本流程的基础上进行裁减。
1.3.1 软件配置管理（Software Configuration Management，SCM）
软件配置管理是对软件修改进行标识、组织和控制的技术，用来协调和控制整个过程。是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。
配置是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此配置包括了即将受控的所有产品特性，其内容及相关文档、软件版本、变更文档、软件运行的支持数据，以及其他一切保证软件一致性的组成要素，相对与硬件类配置，软件产品的配置包括更多的内容并具有易变性。
1.3.3 配置项（Configuration Item，CI）
凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item, CI），配置项逻辑上组成软件系统的各组成部分，一般是可以单独进行设计、实施和测试的。一个纯软件的CIs通常也称之为软件配置项（Computer Software Configuration Items，CSCIs）。
配置项主要有两大类：
1)属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等；
2)项目管理和机构支撑过程产生的文档。这些文档虽然不是产品的组成部分，但是值得保存。
每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。
在配置管理系统中，基线就是一个CI或一组CIs在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，些配置项构成了一个相对稳定的逻辑实体，而这个过程被称为“基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素（配置项）的一个版本，且只确定一个版本。一般情况下，基线一般在指定的里程碑（Milestone）处创建，并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制，基线中的配置项被“冻结”了，不能再被任何人随意修改，对其的修改将严格按照变更控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线。
基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。
建立基线的好处：
1)重现性：及时返回并重新生成软件系统给定发布版的能力，或者是在项目中的早些时候重新生成开发环境的能力。当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
2)可追踪性：建立项目工件之间的前后继承关系。目的是确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。
3)版本隔离：基线为开发工件提供了一个定点和快照，新项目可以从基线提供的定点之中建立。作为一个单独分支，新项目将与随后对原始项目（在主要分支上）所进行的变更进行隔离。
责任：
1)与CCB协商确定项目起始基线和开发里程碑；
2)接受配置管理计划，并按相关规定贯彻执行；
3)接受配置控制委员会的报告。
权利：
1) 提出配置管理计划的修改要求；
2) 提出管理管理的建议和要求。
2.2 配置控制委员会（Configuration Control Board，CCB）
责任：
1) 制定和修改项目的配置管理策略；
权利：
1) 批准、发布配置管理计划；
2) 建立、更改基线的设置，审核变更申请；
3)根据配置管理员的报告决定相应的对策。
2.3 配置管理员（Configuration Management Officer，CMO）
责任：
1)编制配置管理计划；
2)执行配置项管理方案；
3) 执行版本控制和变更控制方案；
4)编制配置状态报告；
权利：
向CCB汇报有关配置管理流程中的不符合情况。
2.4 程序库管理员（Program Librarian，PL）
责任：
1)配置库的建立和权限分配；
2)配置管理工具的日常管理与维护；
3) 配置库的日常操作和维护；
权利：
最低0.47元/天 解锁文章
6308
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
