CMMI2级——度量与分析(Measurement and Analysis, MA)
它事 成熟度第二级的支持类【过程域】
度量的目标:
- 改进开发过程
- 改进项目控制
- 缩短项目周期
- 减少开发成本
- 提升软件质量
- 提升软件性能
- 提高劳动生产率
度量的目的:
开发和维护度量能力，以支持对管理信息的需要
特定目标:
特定目标
SG 1 分配度量和分析活动
度量的目标和活动与识别出的信息需求取得一致
- SP 1.1 建立度量目标
- SP 1.2 详细说明度量
- SP 1.3 指定 数据收集与存储流程
- SP 1.4 指定 分析流程
SG 1 分配度量和分析活动
SG 2 提供度量结果
提供了满足信息要求的度量结果
- SP 2.1 收集度量数据
- SP 2.2 分析度量数据
- SP 2.3 存储数据和结果
- SP 2.4 提交结果
提供度量结果
CMMI2级——供应商协议管理(Supplier Agreement Management)
做软件开发的，不免要购买一些软硬件。软件可能是中间件、控件、插件、组件等，硬件可能是一些服务器、PDA、单片机等。只要稍微复杂的项目，都不可避免的会有采购的问题，就算目前没有采购，以后也会不可避免。另外也有可能把项目的一部分外包给第三方来做。
特定目标和特定实践
SG1：签订供应商协议：
- SP1.1确定采购方式
- SP1.2选择供应商
- SP1.3签订供应商协议
SG2：履行供应商协议：
- SP2.1执行供应商协议
- SP2.2监督选定的供应过程
- SP2.3评价供应商产品
- SP2.4验收采购的产品
- SP2.5移交产品
特定目标和特定实践
SAM这个PA，简单的说可以分为4点：
1)分析项目什么东西需要采购或者外包。
2)选择合适的供应商。
3)和供应商签署协议，协议要写明产品规格要求、验收要求、双方的活动、交付要求等，尽可能明细。
4)履行供应商协议。
CMMI2级——配置管理(Configuration Management) （重点）
需求计划承诺等变更而产生的变化会接连不断地发生，所有这些变化最终将体现在多人共同创建的包含源代码、数据或者文档的文件中所发生的变化。
为了避免项目在变更时失控，正确控制和管理变更时很必要的
软件配置管理是项目管理中专用于关注系统地控制项目进行中发生变更的那些部分，由用来识别机构软件产品并控制其修改的一系列活动构成
配置：
是在技术文档中明确说明最终组成软件产品的功能或者物理属性，它包括了即将受控的所有产品特性、内容及其相关文档，而且包括软件版本、变更文档和软件运行的支持数据，以及其他一切保证软件一致性的组成要素
配置项
凡是纳入配置管理范畴的 工作成果 统称为配置项（CI）。
配置项主要有两大类：
- 属于产品组成部分的工作成果，例如源代码、需求文档、设计文档和用户说明书等等即目前公司采用的配置项。
- 在管理过程中产生的文档例如各种周报、监控报告等等，这些文档虽然不是产品的组成部分，但是值得保存，也就是我们的数据项。
每个配置项的主要属性有：名称、标识符、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程
配置项特点：
- 它会被两个或两个以上的项目成员共同使用。
- 它会随着项目的开展而发生变化。
- 对项目重要的工作产品。
- 一些工作产品之间的关系非常紧密，一个变化其他的就会受
到影响。 - 配置项本身的变化可以使用“版本管理”对其进行控制
配置管理主要任务
- 识别在指定时间形成基线的产品配置
- 控制配置项变更
- 由配置库构建和发布产品
- 提供精确的配置状态
- 维护在整个软件生命周期中配置的完整性和可跟踪性
软件配置管理活动可归结为4个主要功能
- 配置识别
- 变更控制
- 配置状态统计
- 配置审核 （正式审核，非正式审核）
基线Baseline
定义:
已经正式通过复审核批准的某规约或者产品，它因此可以作为进一步开发的基础，并且只能通过正式的变化控制过程改变
软件文档或源码(或其它产出物)的一个稳定版本,它是进一步开发的基础。
由一组配置项组成，这些配置项构成了一个相对稳定的整体。基线中的配置项被“冻结”了，不能再被任何人随
意修改。
经过正式评审和认可的一组软件配置项，此后，它们将作为下一步开发工作的基础，而且只有通过正式的变更控制流程才能被更改，例如设计说明书是编码的工作的基础，它可以成为软件基线
里程碑（可以有多个）：基线通常对应于项目/开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线。
主要属性：名称、标识符、版本、日期等
正式标准：基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。
更改：对基线的更改必须遵循变更控制规程。
"放行"基线：交付给外部顾客的基线
"构造"基线：内部使用的基线
软件配置管理的目的 ：
在项目的整个软件生命周期内建立并维护软件项目产品的完整性，记录并报告配置的状态，验证配置项的完整性和正确性。
建立和维护工作产品的完成性，使用配置项，配置控制，培植状态统计和配置审计。
通过配置标识、配置控制、配置状态报告和配置审计等手段，建立和维护工作产品的完整性。
特定目标和特定实践
软件配置管理
配置管理---【SG1建立基线】
SG1建立基线
SP1：识别出需要置于配置管理之下的的配置项、组件和相关的工作产品
SP2：建立和维护配置管理和变更管理的系统以控制工作产品
- 协同开发的基础:控制进度、质量
- 公司资产的生命线
- 要求开发人员改变一些工作习惯
SP3：创建和发布了内部使用以及发布给客户的基线
--------实现活动--基线控制--------
- 计划
- 需求分析
- 设计
- 编码
- 测试
基线控制
--------控制方法--版本--------
基本就是git里面那些东西，大概看一看
版本的访问
版本的访问
版本的分支
是软件配置项同时沿着两个或多个分支展开，新版本独立地添加到各自的分支中
版本的分支
版本的合并
是软件配置项同时沿着两个或多个分支展开，新版本独立地添加到各自的分支中
版本的合并
版本控制
通过分支和合并为并行开发提供支持
- 并行开发允许不同的项目在同一时间使用相同的原文件；
- 并行开发隔离了那些永远不被共享的工作；
- 并行开发允许工程师即使某一条开发线被冻结了，仍可以沿着一个分支继续开发。
分支、合并、比较
文件比较－用来比较两个或多个分支或基线中具有相同名字的文件，并识别这些不同的文件。
分支作用
分支作用:
- 缺陷修正
- 多版本
- 并行开发
所有合并必须合并到主分支
所有合并必须合并到主分支，子分支完成合并后，不再演进
适用于对软件缺陷的修正工作管理
一个子分支的演进可以通过主分支传递给其他子分支
但是所有的变化均要反映到主分支，各个分支均可进行合并
适用于具有核心版本的产品
围绕核心版本推进各个分支的演进
一个子分支的演进可以通过主分支传递给其他子分支
配置管理---【SG2跟踪和控制变更】
在配置管理之下的配置项变更得到跟踪和控制
跟踪和控制变更
SP 2.1:跟踪配置项的变更请求
SP 2.2:控制配置项的变更
- 组建CCB (变更控制委员会英文缩写）
- 要规定控制级别！
- 要确认变更实施
--------变更管理任务--------
变更控制的目的 不是为了防止变更，而是管理变更
变更控制的目的 是防止配置项被随意修改而导致混乱。
软件变更的不可避免性
错误更正
产品改进
需求变更
软件变更的复杂性
软件配置项数量大
版本多
变更的迁延性
人员沟通协调
变更管理的任务
分析变更
记录和追踪变更
采取措施保证变更在受控状态下进行
变更管理任务
--------控制基线的变更--------
目的
识别变更授权人
维护配置的稳定性和完整性
确保变更控制的有效性
定义变更权威---》控制变更---》管理问题报告
--------变更管理--------
变更管理是配置管理的一个重点和难点。
当基线库配置项需要变更时，一定要实施变更流程：
变更实施前必须填写《变更申请表》，
经CCB评审通过后，
才能从基线库中提出需变更的配置项并实施变更。
变更实施完成后，必须通过评审验证才能重新进入基线库。
变更流程
--------配置变更委员会CCB-------
授权进行正式基线变更的机构
职能：
确保变更被分类以及被评估
决定需要实施的变更的优先级
评审和批准变更
确保只有被批准的变更得到实施
CCB成员最好各司其职,成员可能包括：
项目经理，配置管理员，质量保证人员，开发人员代表，客户代表
配置管理---【SG3建立完整性】
基线的完整性得到了建立和维护
建立完整性
SP 3.1：建立和维护描述配置项的配置记录
记录变更
记录基线状态
发布状态报告
SP 3.2：执行了配置审计以维护配置基线的完整性
功能审计和物理审计
产品/基线出门前的保证
配置状态报告
一种配置管理活动
目的是向项目所有成员提供已批准的基线和过程的当前状态，也提供基线变更信息。报告的方式可以多种多样，如发OA、Email
应该把握好时机：变更请求被批准时；建立基线及基线版本发生变化时；项目组任何需要的时候。
配置审计
定义：对于存储配置项及相关记录的软件基线库的结构、内容和设施进行检验，其目的在于验证基线是否符合描述基线的文档。
配置审计的目的就是要保证所有人员（包括配置管理员、CCB、和普通项目成员）都遵守配置管理规范。
可以作为变更控制的补充手段，来确保某一变更需求已被切实实现。
配置审计包括三方面的内容：基线发布审计、产品发布审计、日常审计。
配置审计的对象是项目的主要配置项
验证内容包括：
对于产品的功能和性能的需求作比较，可参考需求跟踪矩阵
配置项的处理是否有背离初始的规格说明或已批准的变更请求的现象
配置标识的准则是否得到了遵循；
变更控制规程是否以遵循，变更记录是否可供使用
是否保持了可追溯性。
配置审核工作：
功能配置审核(FCA)——验证配置项的实际功效是与其软件需求一致的。
物理配置审核(PCA)——确定配置项符合预期的物理特性，即特定的媒体形式。
功能配置审计可以包括按测试数据审计正式测试文档、审计验证和确认报告、评审所有批准的变更、评审对以前交付的文档的更新、抽查设计评审的输出、对比代码和文档化的需求、进行评审以确保所有测试已执行。功能配置审计还可以包括依据功能和性能需求进行额外的和抽样的测试。
物理配置审计可以包括审计系统规格说明书的完整性、审计功能和审计报告、了解不符合采取的措施、对比架构设计和详细设计组件的一致性、评审模块列表以确定符合己批准的编码标准、审计手册（如用户手册、操作手册）的格式、完整性和与系统功能描述的符合性等。
--------审计－工作步骤--------
-
由项目经理决定何时进行配置审计工作
-
质量保证组或软件组的配置管理组指定该项目的配置审计人员
-
项目经理和配置审计员决定审核范围。
-
配置审计员准备配置审计检查单
-
配置审计员安排时间审核文档和记录，审核活动可能涉及到：
项目范围配置项的检入（check-in）及检出（check_out）
评审记录配置项的变更历史
测试记录文件的命名
变更请求版本的编号 -
配置审计员在审核中发现不符合现象，并作记录。
-
由项目经理负责消除不符合现象。
-
配置审计员验证所有发现的不符合现象确已得到解决。
实现中的配置管理基本流程
变更会涉及到的配置项分析实例
网友评论