CMMI 总结 part.2 (v1.00)

2020-12-29  本文已影响0人  constantine丶

CMMI2级——度量与分析(Measurement and Analysis, MA)

它事 成熟度第二级的支持类【过程域】

度量的目标:

度量的目的:

开发和维护度量能力，以支持对管理信息的需要

特定目标:

特定目标

SG 1 分配度量和分析活动
度量的目标和活动与识别出的信息需求取得一致

SG 1 分配度量和分析活动

SG 2 提供度量结果
提供了满足信息要求的度量结果

提供度量结果

CMMI2级——供应商协议管理(Supplier Agreement Management)

做软件开发的，不免要购买一些软硬件。软件可能是中间件、控件、插件、组件等，硬件可能是一些服务器、PDA、单片机等。只要稍微复杂的项目，都不可避免的会有采购的问题，就算目前没有采购，以后也会不可避免。另外也有可能把项目的一部分外包给第三方来做。

特定目标和特定实践

SG1：签订供应商协议：

SG2：履行供应商协议：

特定目标和特定实践

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成员最好各司其职,成员可能包括：
 项目经理，配置管理员，质量保证人员，开发人员代表，客户代表

配置管理---【SG3建立完整性】

基线的完整性得到了建立和维护

建立完整性

SP 3.1：建立和维护描述配置项的配置记录
 记录变更
 记录基线状态
 发布状态报告

SP 3.2：执行了配置审计以维护配置基线的完整性
 功能审计和物理审计
 产品/基线出门前的保证

配置状态报告
一种配置管理活动
目的是向项目所有成员提供已批准的基线和过程的当前状态，也提供基线变更信息。报告的方式可以多种多样，如发OA、Email
应该把握好时机：变更请求被批准时；建立基线及基线版本发生变化时；项目组任何需要的时候。

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

 配置审计的目的就是要保证所有人员（包括配置管理员、CCB、和普通项目成员）都遵守配置管理规范。
 可以作为变更控制的补充手段，来确保某一变更需求已被切实实现。
 配置审计包括三方面的内容：基线发布审计、产品发布审计、日常审计。
 配置审计的对象是项目的主要配置项

验证内容包括：
 对于产品的功能和性能的需求作比较，可参考需求跟踪矩阵
 配置项的处理是否有背离初始的规格说明或已批准的变更请求的现象
 配置标识的准则是否得到了遵循；
 变更控制规程是否以遵循，变更记录是否可供使用
 是否保持了可追溯性。

配置审核工作：
 功能配置审核(FCA)——验证配置项的实际功效是与其软件需求一致的。
 物理配置审核(PCA)——确定配置项符合预期的物理特性，即特定的媒体形式。

功能配置审计可以包括按测试数据审计正式测试文档、审计验证和确认报告、评审所有批准的变更、评审对以前交付的文档的更新、抽查设计评审的输出、对比代码和文档化的需求、进行评审以确保所有测试已执行。功能配置审计还可以包括依据功能和性能需求进行额外的和抽样的测试。

物理配置审计可以包括审计系统规格说明书的完整性、审计功能和审计报告、了解不符合采取的措施、对比架构设计和详细设计组件的一致性、评审模块列表以确定符合己批准的编码标准、审计手册（如用户手册、操作手册）的格式、完整性和与系统功能描述的符合性等。

--------审计－工作步骤--------

实现中的配置管理基本流程 变更会涉及到的配置项分析实例
上一篇 下一篇

猜你喜欢

热点阅读