CMMI中配置管理

1. 产品完整性：就是项目提交的工作成果是“产品集合完整、 子产品的正确”的 2. 产品集合完整：产品包含的子产品（配置项）是完整的 3. 子产品的正确：子产品（配置项）达到了需求要求，满足 标准、规程的要求
配置和配置项 在配置管理中，“配置”和“配置项”是重要的概念，“配置”是在技 术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置” 包括了即将受控的所有产品特性，其内容及相关文档，软件版本，变更 文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素， 相对与硬件类配置，软件产品的“配置”包括更多的内容并具有易变性。 受控软件经常被划分为各类配置项（Configuraion items, CIs），这类 划分是进行软件配置管理的基础和前提，CIs是逻辑上组成软件系统的各 组成部分。比如一个软件产品包括几个程序模块，每个程序模块及其相 关文档和支撑数据可能被命名为一个CI。一个系统包括的CIs的数目是一 个与设计密切相关的问题。一个纯软件的CI通常也称之为软件配置项 （CSCI）。 现在所有的配置管理工具均提供对配置项的管理工具，包括(Check in 和Check out机制的 )版本管理和版本标号功能。由于版本和标号管理比 较繁琐，一般推荐使用配置管理工具，减少事务性工作。
在CMMI中，将配置管理的目的定义为“建立和维护产品的 完整性”，这个目标没有提到对项目管理的支持，也就是说， 它定义的配置管理的目标比当前业界对配置管理的认识有些 缩小。但是，仔细分析可以发现“建立和维护产品的完整性” 是其他配置管理目标的基础。下面就从这个目标出发进行分 析。逻辑关系见下图：
配置完整性（对标准的理解） 配置完整性（对标准的理解）
基线具有以下属性： 基线具有以下属性： 1.通过正式的评审过程建立 2.基线存在于基线库中，对基线的变更接受更高权限的控制 3.基线是进一步开发和修改的基准和出发点 4.进入基线前，不对变化进行管理或者较少管理 5.进入基线后，对变化进行有效管理，而且这个基线作为后继续工作的 基础 6.不会变化的东西不要纳入基线 7.变化对其他没有影响的可以不纳入基线
配置审计 配置审计的主要作用是作为变更控制的补充手段，来确保某 一变更需求已被切实实现。在某些情况下，它被作为正式的 技术复审的一部分，但当软件配置管理是一个正式的活动时， 该活动由SQA人员单独执行。 审计机制保证修改的动作被完 整地记录，也就是说，记录了谁修改了这个工件，什么时候 做的修改，为什么原因做出这个改动，以及修改了哪些地方。 在版本控制过程中，如果利用一些配置管理工具（或者版本 控制工具）的支持，则可以自动地记录审计工作所需的四个 “W”（Who、When、Why、What）。 同时配置审计工作 应当可以说明如下信息。
配置库的日常工作 配置库的日常工作是一些事务性的工作，主要保证配置 库的安全性，包括：
1.对配置库的定期备份 2.清除无用的文件和版本 3.检测并改进配置库的性能等
配置状态报告就是根据配置项操作的记录来向管理者报告软 件开发活动的进展情况。这样的报告应该是定期进行，用数 据库中的客观数据来真实的反映各配置项的情况。 配置状态报告应着重反映当前基线配置项的状态，以作为对 开发进度报告的参照。为了说明项目状态对变更的情况也应 当进行报告。有时，对配置库的情况也进行说明，例如备份 次数，磁盘占用空间等等。只要是关心的信息，均可作为状 态报告的内容。这些信息进行有效记录，往往可以作为项目 度量的重要数据来源。
基线 在配置管理系统中，基线就是一个CI或一组CIs在其生命周期的不同时间 点上通过正式评审而进入正式受控的一种状态，而这个过程被称为“基 线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了 元素（配置项）的一个版本，且只确定一个版本。一般情况下，基线一 般在指定的里程碑处创建，并与项目中的里程碑保持同步。 一般地，第一个基线包含了通过评审的软件需求，因此称之为“需求基 线”，通过建立这样一个基线，受控的系统需求成为进一步软件开发的 出发点，对需求的变更被正式初始化、评估。受控的需求还是对软件进 行功能评审的基础。 每个基线都将接受配置管理的严格控制，对其的修改将严格按照变更 控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增 加和修改的基线内容形成下一个基线，这就是“基线管理”的过程。
配置审计应当说明的信息： 1. 变更要求被完成，并且对附加的修改已经执行了 2. 采用了正确的正式验证手段 3. 遵循了标准的要求 4. 变更的4W信息被完整记录，并和相关配置项关联
项目实施指南 一个软件研发项目一般可以划分为三个阶段：计划阶段、开发阶段和维 护阶段。然而从软件配置管理的角度来看，后两个阶段所涉及的活动是 一致，所以就把它们合二为一，成为“项目开发和维护”阶段。 一个项目设立之初项目经理首先需要制定整个项目的计划，它是项目研 发工作的基础。在有了总体研发计划之后，软件配置管理的活动就可以 展开了，因为如果不在项目开始之初制定软件配置管理计划，那么软件 配置管理的许多关键活动就无法及时有效的进行，而它的直接后果就是 造成了项目开发状况的混乱并注定软件配置管理活动成为一种“救火” 的行为。所以及时制定一份软件配置管理计划在一定程度上是项目成功 的重要保证。 在“开发阶段和维护阶段”，软件配置管理活动主要分为三个层面，这 三个层面是彼此之间既独立又互相联系的有机的整体。 （1） 主要由配置人员完成的管理和维护工作； （2） 由系统集成员和开发人员具体执行软件配置管理策略； （3） 变更流程。
基线管理的步骤： 基线管理的步骤： 1、在开发前确定基线的“配置” 2、基线批准前，根据“配置”检查配置项是否齐备 3、对各个配置项，确认其版本的正确性 4、对每个配置项建立基线标志， 5、基线变更管理 6、基线的各类报告和审计信息
变更管理
在有效标示了配置并进行了管理之后，如何保证它们在复杂多变得开发 过程中真正的处于受控的状态，并在任何情况下都能迅速的恢复到任一 历史状态就要依赖以下的变更管理。
变更管理的流程： 变更管理的流程： 1.（获得）提出变更请求； 2.由CCB审核并决定是否批准； 3.为（被接受）修改请求分配Байду номын сангаас员，提取SCI，进行修改； 4.提交修改后的SCI，并测试（或者评审）； 5.重建软件的适当版本； 6.复审（审计）所有SCI的变化； 7.发布新版本。
配置库管理 在实际的开发活动中系统中，为了让每个开发人员和各个开 发团队能更好的分工合作，同时又互不干扰，必须规划好工 作空间的管理。主要的手段是设置配置库（即文件夹设 置），和设置版本的分支，来实现对配置项权限管理。