软件过程和项目管理（CMMI配置管理）

软件配置管理：

需求计划承诺等变更最终体现在多人共同创建的源代码、数据、文档中所发生的变化

为避免项目在变更时失控，需要正确控制和管理变更

专用于关注系统地控制项目进行中发声变更的那些部分，由用来识别机构软件产品并控制其修改的一系列活动构成

 

软件配置管理目的：

在项目的整个软件声明周期内建立并维护软件项目产品的完整性，记录并报告配置的状态，验证配置项的完整性和正确性

配置管理的目的：建立和维护工作产品的完成性，使用配置项，配置控制，配置状态统计和配置审计

通过配置标识、配置控制、配置状态报告、配置审计等手段，建立和维护工作产品的完整性。

 

配置管理主要任务:

1.识别在指定时间形成基线的产品配置；

2.控制配置项变更；

3.由配置库构建和发布产品；

4.提供精确的配置状态；

5.维护在整个软件生命周期中配置的完整性和可跟踪性

配置管理实现路径：

 

基本概念：

配置：

在技术文档中明确说明最终组成软件产品的功能或者物理属性，

包括了即将受控的所有产品特性、内容及其相关文档，包括软件版本、变更文档和软件运行的支持数据及其他一切保证软件一致性的组成要素

配置项：纳入配置管理范畴的工作成果

1.属于产品组成的工作成果，如源代码、需求文档、设计文档和用户说明书等

2.在管理过程中产生的文档，如周报、监控报告等

每个配置项主要属性有：名称、标识符、版本、作者、日期等。所有配置项都保存在配置库中，反映软件的演化过程。

配置项特点：

1.会被两个及以上成员共同使用；

2.随着项目的开展而发生变化；

3.对项目重要的工作产品；

4.一些工作产品之间关系紧密，一个变化会导致其他的收到影响；

5.配置项本身的变化可以使用版本管理对其进行控制

 

软件配置管理活动：

配置识别，变更控制、配置状态统计、配置审核（正式审核、非正式审核）

 

基线：已经正式通过复合批准的某规约或者产品，它因此可以作为进一步开发的基础，并且只能通过正式的变化控制过程改变

软件文档或者源码（其他产物）的一个稳定版本，进一步开发的基础

由一组配置项组成，这些配置项构成一个相对稳定的整体，基线中的配置项不能在被任何人随意修改

通常对应于项目/开发过程中的里程碑，一个产品可以有一个或者多个基线

主要属性有：名称、标识符、版本、日期等

基线是项目储存库中每个工件版本在特定时期的一个“快照”。他提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准；

对基线的更改必须遵循变更控制规程

交付给外部顾客的基线为“放行”基线，内部使用的为“构造”基线

 

CMMI中的配置管理：

1.建立基线

1.1识别需要置于配置管理的配置项、组件和相关的工作产品；

1.2建立和维护配置管理和变更管理的系统以控制工作产品：

协同开发的基础：控制进度、质量

公司的资产生命线

要求开发人员改变一些工作习惯

1.3创建和发布内部使用以及发布给客户的基线

 

实现活动--基线控制

计划基线、需求基线、设计基线、编码基线、测试基线

控制方法：版本

 

版本的分支：软件配置项同时沿着两个或者多个分支展开，新版本独立添加到自己的分支

版本的合并：版本开发完成后，希望合并到基线版本中，作为以后开发新版本的基础

 

版本控制：

1）.通过分支和合并为并行开发提供了支持

允许不同项目在同一时间使用相同的原文件；隔离了永不被共享的文件；允许工程师即使某条线被冻结，仍可沿着另一个分支继续开发

2）.文件比较：用来比较两个或者多个分支（基线）中具有相同名字的不同文件，并识别这些不同的文件

 

2.跟踪和控制变更

2.1跟踪配置项的变更请求

2.2控制配置项的变更

组件CCB;要规定控制级别；要确认变更实施

 

变更管理的任务：

1、软件变更的不可避免性：错误更正、产品改进、需求变更

2、软件变更的复杂性：配置项数量大、版本多、变更的迁延性、人员沟通协调

3、变更管理的任务：分析变更、记录和追踪变更、采取措施保证变更在受控状态下进行

 

控制基线的变更：

1.识别变更授权人；2.维护配置的稳定性和完整性；3.确保变更控制的有效性

 

变更管理：

防止配置项被随意修改导致混乱

基线库配置项实施变更时，一定要实施变更流程：申请、评审、提出配置项并实施变更、评审后重新入基线库

 

配置变更委员会CCB：授权进行正式基线变更的机构

职能：确保变更被分类以及被评估；决定需要实施的变更的优先级；评审和批准变更；确保只有别批准的变更得到实施；

成员各司其职：项目经理、配置管理员、质量保证人员、开发人员代表、客户代表

 

3.建立完整性

3.1建立和维护描述配置项的配置记录

记录变更、记录基线状态、发布状态报告

3.2执行配置审计以维护配置基线的完整性

功能审计和物理审计；产品基线出门前的保证

 

配置状态报告：向项目所有人提供已批准的基线和过程的当前状态

配置审计：保证所有人都遵守配置管理规范；可以作为变更控制的补充手段；

配置审计包括基线发布审计、产品发布审计、日常审计；审计对象是主要配置项

配置审计是指对存储配置项及相关记录的软件基线库的结构、内容、和设施进行检验，其目的在于验证基线是否符合描述基线的文档

验证内容包括：

1）对于产品的功能和性能的需求作比较，可参考跟踪矩阵；

2）配置项的处理是否有背离初始的规格说明或已批准的变更请求；

3）配置标识的准则是否得到了遵循；

4）变更控制规程事发后得到了遵循，变更记录是或否可供使用；

5）是否保持了可追溯性

 

配置审核工作：

功能配置审核（FCA）：验证配置项的实际功能和软件需求的一致性；

物理配置审核（PCA）：确定配置项符合预期的物理特性，即特定的媒体形式