A、主要目标:
规范配置管理活动,确保配置项正确地唯一标识并易于存取,保证基准配置项的更改受控,明确基线状态,在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。
B、配置项包括的范围:
1、标识需要进行存储的工件(Artifact)并保障安全存储;
1.1 存储范围包括:各种正式文档、模型文件、源代码、发布版本、测试脚本等,一切认为有必要保存的东西。(由使用组织决定)
1.2 存储能力要求:容错能力、高可靠性、可扩展性(数据的存储量,保证运行效率)、良好规划的备份和灾难恢复过程。
2、控制并且审计(Audit)对于工件的修改;
2.1 控制机制必须保证只有拿到授权的人员才能对相关工件进行修改,而审计机制则保证修改的动作被完整地记录,记录内容包括4W(who,when,why,what)。
2.2 审计机制通过“检出/检入”(Check out/Check in)模式得到实现。在这种模式下,工件一旦入库,读写权限就变成只读(read only),如果要对该工件进行修改,则需要通过“检出”这个步骤;在修改结束以后,如果希望将修改的成果入库,则需要通过“检入”这个步骤。在经过一次“检出/检入”步骤以后,会形成该工件新的版本,因此也有人把上边的过程称之为“版本控制”(Version Control)。
3、设立并管理基线(Baseline);
3.1项目可以从基线提供的定点之中建立。
3.2当认为更新不稳定或不可信时,基线为团队提供一种取消变更的方法。
3.3可以利用基线重新建立基于某个特定发布版本的配置,这样也可以重现被报告的错误。
4、记录并跟踪变更请求;
4.1 记录,管理和追踪变更请求。
4.2 提供完备的电子邮件自动通知功能。
4.3 可以随时理解变更请求的状态,信息,生成多种统计分析图和项目状态报告。(可以通过浏览器浏览。)
4.4 可以控制各种变更请求之间的关系。
注:具体内容你参考<IBM完整的变更请求管理解决方案>和<变更请求管理>
5、维护稳定、一致的工作空间;
5.1 工作人员可以建立私有工作空间,首要性能稳定,与其他工作人员空间隔离
5.2 灵活方便的共享性,可以共享工作成果。
6、支持对于工件和控件的并发修改;
7、尽早集成、持续集成;
8、保证软件构建的重现能力;(由基线控制)
9、以控件(Component)为单位实施版本控制;(由基线控制)
10、使用“活动”(Activity)来组织和整合版本集。(由基线控制)