文章目录
- 一、CMM/CMMI与软件配置管理
- 产品完整性
- 二、三库管理
- 三、基线管理
- 基线管理的好处
- 基线管理的步骤
- 四、配置库管理
- 五、变更管理
- 变更管理流程
- 六、配置审计
- 七、配置状态报告
一、CMM/CMMI与软件配置管理
软件配置管理是CMM/CMMI二级（可重复级）的一个重要KPA。
CMM/CMMI又将软件配置管理的目的定义为建立和维护产品的完整性。
产品完整性
项目提交的工作成果是产品集合完整、子产品正确的。
- 产品集合完整：产品包含的子产品是完整的；
- 子产品正确：子产品达到了需求要求，满足标准、规程的要求。
二、三库管理
配置项在开发库、受控库和产品库之间迁移，一级比一级的控制更加严格。
在CMM中，对开发库的管理没有要求，但要对受控库和产品库进行管理。
- 开发库
存放开发过程中需要保留的各种信息，供开发人员专用； - 受控库
在软件开发某个阶段工作结束后，将产品或有关信息存入； - 产品库
在软件产品完成系统测试后，作为最终产品存入库内。
按照三库管理的思路，软件开发组日常的工作在开发库中开展，当工作达到里程碑时，再迁移到受控库，在受控库中经过更加严格的测试后，再上升到产品库，最后发布。
三库间通常通过权限与流程控制实现配置项再不同库之间的流转以及人员访问。即逻辑独立，物理上在一起。
三、基线管理
每个基线都接受配置管理的控制，对其的修改将按照变更控制的要求进行。在一个软件开发阶段结束时，上一个基线加上增加和修改的内容形成下一个基线。
基线管理的好处
- 重现性：及时返回并重新生成软件系统版本的能力。
- 可追踪性：建立项目工作之间的前后继承关系。
- 版本隔离：基线为开发工件提供了一个定点和快照，新项目可以中基线提供的定点中建立。
基线管理的步骤
- 在开发前确定基线的配置
- 在批准基线前，根据配置检查配置项的完整性
- 对每个配置项，确定版本的正确性
- 为每个配置项建立基线标志
- 基线变更管理
- 基线报告和审计信息
四、配置库管理
每个配置项从建立开始，就被划分成3个分支：私有分支、集成分支和公共（主干）分支，分别对应三类工作空间，由CMO统一管理。
- 私有分支：是开发人员的私有开发空间，除该开发人员外，其他人无权操作；
- 集成分支：对应开发团队的公共空间，开发团队拥有读写权限，而其他成员只有只读权限，SIO和相关指定负责人进行管理；
- 公共分支：对应整个软件开发组织的公共空间。对全体人员只开发只读权限，由SIO负责管理。
决定配置库的结构是配置管理活动的重要基础，一般常用的是两种组织形式：按配置类型分类建库和按任务建库。
五、变更管理
保证配置项在开发过程中始终处于受控状态，且在任何情况都能迅速恢复到任一历史状态。
为了更好知道变更范围的影响分析，可以通过《需求追踪表》和《配置项依赖关系表》发现受到影响的内容。
变更管理流程
- 提出变更请求
- CCB审核并决定是否批准
- 分配人员，提取SCI，进行修改
- 提交修改后的SCI，并测试
- 重建软件版本
- 复审所有SCI的变化
- 发布新版本
六、配置审计
作为变更控制的补充手段，确保变更需求已被切实实现。审计机制保证修改的动作被完整地记录。
配置审计有两种，分别是物理审计和功能审计。
- 物理审计（PCA）：检查版本是否正确一致（完整性）。一般由非配置管理人员进行，如SQA（质量保证人员）
- 配置项是否齐备
- 版本是否齐全
- 功能审计（FCA）：检查配置项是否完整，各种过程文档是否齐备、正确、与需求是否一致（一致性），归结为两点，即完全和齐备。一般由CMO进行。
七、配置状态报告
配置状态报告就是根据配置项操作的记录来向管理者报告软件开发活动的进展情况。通常是定期进行、通过case工具自动生成的。着重反应当前基线配置项的状态，对变更情况和配置库情况也应进行说明。
