解读CMMI-DEV1.2到1.3的变化
解读CMMI-DEV1.2到1.3的变化本文作者：YvonneJenny 源文链接：
blog/user7/YvonneJenny/archives/2011/82995.html
2010年12月，CMMI DEV1.3正式发布。在CMMIV1.3发布前，SEI作了大量的宣传，称1.3有很大的改进。的确如SEI遵循的原则，CMMI模型要体现业内的最佳实践(Best Practice)。CMMI DEV1.3在吸纳目前业内的一些好的实践的同时，还吸纳了ISO以及PMI的一些新的成果。其主要变化包括：
1、 吸收了敏捷软件开发的实践。在配置管理（CM）、技术解决方案（TS）、产品集成（PI）、验证（VER）、确认（VAL）、需求管理（REQM）、质量保证（PPQA）等过程域中，对敏捷软件开发相关一些实践作了说明；
2、 对高成熟度的4个过程域作了较大优化，以“反应业界的最佳实践”。感觉现在这几个过程域的实践不再像之前那样高不可攀，很多解释似乎不再像从前那样机械，而且把过程改进目标与组织商务目标相联系，增加了一些具体的例子，对实践有一定指导作用。同时，该版本中删掉了原来高成熟度等级中的共性目标。连续型模型中只包含了3个级别，不再有高成熟度等级。
3、 更加重视需求管理：该版本将需求管理（REQM）过程域从工程组（Engineering）移至项目管理组（Project Management）。
4、 更加关注结果。这表现在一些名词的提法，如：
“管理过程(Manage Process)”变成“管理项目(Manage Project)”；
共性实践GP2.6的标题从“管理配置项”更改为“控制工作产品”，虽然内容基本没有变化；
共性实践GP2.9 “客观评价依从性”中将原来“客观评价过程的依从性”，更改为“客观评价过程和工作产品的依从性”；
5、 吸纳了ISO、PMBOK等的一些最新成果。例如：
原来的“需求”变成了“功能需求和质量属性（Quality Attributes）”;
增加了架构评审的一些实践
更加强调各过程与组织商务目标的关系
6、 其他：删除了所有IPPD（Integrated Product and Process Development）的相关内容。（事实上，IPPD是在1.2版中强塞进去的，与模型的其它部分融合度很差。）
下面按照成熟度等级对各PA的变化进行简要说明。
二级过程域的主要变化
1
CM(Configuration Management) ——配置管理
2 变化点
在配置项的例子中增加硬件、环境配置、工具等内容
强调了基于核心产品的产品线开发中，多分支配置管理的复杂性
强调了在敏捷开发环境中进行频繁变更、持续集成，导致配置管理工作的复杂性和重要性
2 敏捷开发
在Agile环境中，配置管理非常重要。由于要支持经常性变更、经常性构建(通常是每日)、多重基准、以及多重工作场所(例如，对个人、团队、甚至是结对程序)，如果配置管理做不到下列各项，则Agile团队可能陷入泥沼：1) 自动化CM (例如，build scripts、状态记述、完整性检查)；2)将CM当成标准服务执行：在启动的时候，Agile团队应明确配置管理负责人；在每一个迭代周期开始，需要重新确认配置管理的支持是否到位。而配置管理责任人的目标是将配置管理工作谨慎地整合到团队的工作节奏，最小化开发人员重点工作外的其它工作量。
2
PPQA (Process and Product Quality Assurance) —— 过程和产品质量保证
2 变化点
在SP2.2中增加评估工作产品的时机的例子。
增加敏捷开发模式下的质量保证活动建议
2 敏捷开发
在Agile环境中，团队倾向于将焦点聚集在本迭代的立即需要上，忽略较长期的且更广泛的组织利益需要。为了确保客观评估的效果，使之具有价值和效率，需尽早确定：(1)客观评估如何完成；(2)要评估哪些过程与工作产品；(3)评估的结果要如何整合到团队的节奏中(例如，融合到每日例行会议、检查表、同行评审、工具、持续集成等等活动中)。
3
PP (Project Planning) —— 项目规划
2 变化点：
增加对计划的解释，既可以集中在一个文档中，又可以分散
在SG1中删掉了影响估算因素的项目属性的具体说明
SP1.3标题“定义项目生命周期”改为“定义项目生命周期阶段”，计划内容中增加“里程碑”
在项目进展状态评审中强调对客户满意度度量结果的评审
估算方面作了较多修改
2 敏捷开发
对于产品线，多种工作活动集能获益于项目规划过程，这些工作活动包括核心资产的创建与维护、建立在核心资产上的产品开发、以及整个产品线中相关联的小组之间活动的协调。在Agile环境中，实现增量式开发，比传统方法需要更为频繁执行计划、监视、控制、以及重计划活动。虽然会建立整体项目的高层计划，但是团队是以一个增量或迭代进行估算、计划，并执行实际的工作。除了预期的风险、重大事件、以及大规模的影响与限制条件外，团队通常不对项目未知的部分做预测。估算值反映出影响完成该迭代的时间、成本、资源、以及风险等特定的因素。每一迭代周期内，计划、监视、以及调整计划成为经常性的工作。在迭代计划过程中，一个周期完成的任务从待完成的功能中选取，用例细化后用于估算，一旦工作任务分配到个人，对计划的承诺是必须的
4 PMC (Project Monitoring and Control) —— 项目监控
2 变化点：
增加对里程碑评审的详细说明
（监控风险一节）强调项目进行过程中需要不断识别新的风险；
监控干系人参与中强调敏捷开发中客户和最终用户参与的重要性；
在项目进展状态评审中强调对客户满意度度量结果的评审
2 敏捷开发
在Agile环境中，项目产品开发活动中，客户与潜在最终用户的持续参与对于项目成功极其重要；因此，项目活动中，客户与最终用户的参与，应受到跟踪。
5 REQM(Requirements Management) —— 需求管理
2 变化点：
增加在Agile环境中如何进行需求一致性跟踪
2 敏捷开发
在Agile环境中，需求通过产品积存、故事卡、屏幕实体模型之类机制进行交流和跟踪。对需求的承诺，或是以团队集体式做出，或是由团队领导授权做出。根据项目的进展，或随着对需求理解的进一步加深，或解决方案的出现，工作指派频繁地进行调整(每日或每周)。需求与工作产品之间的追踪性与一致性，是通过上面所说的机制完成的，通常在迭**始或迭代结束活动如“回顾”与“展示日”之类中进行的。
6 SAM(Supplier Agreement Management) —— 供应商合同管理
2 变化点：
对sp2.2/2.3/2.4进行合并，将对供应商的过程和产品监控合并到“验收采购产品”，删除了原来2.2和2.3中若干子实践
7 MA(Measurement and Analysis) —— 度量分析
2 变化点
SP2.1标题，由“收集（Collect）度量数据”修改为“获取（Obtain）度量数据”，但内容无变化
对一些度量目标的例子解释得更为详尽
SP1.2 确定度量中，增加了一张表举例说明基本的度量定义——对实际操作更有指导作用
**过程域的主要变化
1 OPD(Organizational Process Definition ) —— 组织过程定义
组织过程定义的目标从原来“建立和维护组织过程资产和工作环境标准”扩充到“建立和维护组织过程资产、工作环境标准以及团队规则和指导方针”；
增加SP1.7“建立团队建设的规则和指导方针”，目标是通过建立和维护组织级的规则和指导方针用以进行项目团队的组织、建设和管理。其实践包括项目的组织架构、项目经理和成员的权利和责任、团队行为准则、内部的计划任务分配检查机制、沟通方式，对外部和客户的汇报方式等等。旨在建立组织级的准则用以指导各项目团队管理。
SP1.3中增加一节强调对标准过程裁减的重要性。强调对于存在特殊需求的项目，对标准过程进行裁减以满足项目特殊的商务目标是非常关键的。
SP1.4增加对度量库的功能描述 —— 有利于项目之间进行有效的比较；在建立新项目时，可以通过度量库快速获得类似项目的基线或历史数据作为参照；可以通过类似项目历史数据提高估算精度；有助于统计管理。
2 OPF(Organizational Process Focus ) —— 组织过程焦点
SP1.3，组织在对需要改进的过程排优先级时，需要从成本收益进行考虑。
3 OT(Organizational Training ) —— 组织培训
在培训需求中增加了领导力培训、团队建设培训以及沟通技巧培训的例子。
4 IPM (Integrated Project Management) —— 集成项目管理
SP1.6前插入新的特定实践“组建项目团队”：包含了原来IPPD中的大部分内容
SP1.5增加子实践“对影响项目目标达成的问题进行根源分析”，目的是在项目或组织范围内采取适当的纠正或预防措施。
5 RSKM (Risk Management) —— 风险管理
基本无变化
6 DAR (Decision Analysis and Resolution) —— 决策分析和解决方案
基本无变化
7 RD (Requirements Development) —— 需求开发
增加了质量属性需求及说明 —— 质量需求，即质量属性的开发，贯穿于整个需求开发过程域中；例如，分解需求中也提到架构设计与质量属性的关系，强调产品质量特性的满足是通过架构设计实现的。
增加在Agile环境下需求存在的形式及文档详细程度的说明；
2 敏捷开发
在Agile环境中，会在每一个迭代周期内反复引导、细化、分析和确认客户需求。需求通过用例、场景甚至迭代结果(在软件情况下为程序代码)的形式记录。哪些需求项会在给定的迭代周期中予以处理，是以风险评估和后续功能列表中的优先级驱动的。需求(及其他工作产品)文档的详细程度，是由团队成员间、团队间、以及前后迭代周期之间协作的需要以及项目或组织遗失相关成果的风险之间平衡的结果决定的。即使客户加入团队，仍然会有独立的客户和产品文件，用于多种解决方案的并行探索。当最终的解决方案确定后相应的需求会分配给适当的团队。
8 TS (Technical Solution) —— 技术解决方案
在需求前增加形容词“功能和质量属性” —— 更加强调对产品的质量要求；
产品的性能用质量属性代替——质量属性具有更宽泛的概念；
在解决方案的选择准则中增加对关键质量属性的考虑，如产品时间特性、安全性、可靠性和可维护性等；
删除了对“Data Package”的具体内容描述。
2 敏捷开发
在Agile环境中，TS的焦点在于对解决方案进行探索。让解决方案的选择准则及选择过程透明，有助于提高决策的质量。解决方案可从功能、特征集、发布版本、或任何其它能产品开发组件的角度来定义。当团队外的某个人在未来为这个产品工作时，产品的发布信息、维护日志、以及其他数据，通常会包含于该已安装的产品中。为支持产品更新，关于接口设计、组件采购和开发的决策准则的记录将有助于后续支持人员对该产品的理解。不过，如果所选解决方案存在的风险越小，则正式进行决策的需要也就越低。
9 PI (Product Integration) —— 产品集成
SP1.1“确定集成顺序（Determine Integration Sequence）”更改为“建立集成策略（Establish an Integration Strategy ）”。集成策略的涵盖的内容更多，除集成顺序外，还包含了对环境、工具、方法以及验证的策略。
2 敏捷开发
在Agile环境中，产品集成是一个经常性、通常是每日进行的活动。例如，对于软件开发，程序代码持续地以称为“持续集成”的过程，加入到程序代码库中。除了进行持续集成之外，产品集成策略还应说明，第三方所提供的组件如何集成到产品中，功能性将如何构建（横向分层还是纵切片)，以及在何时重构(refactor)。集成策略应在项目早期制定，并逐渐修订以以反映组件接口、外部依赖、数据交换、以及应用程序编程接口的演化。
10 VER (Verification) —— 验证
验证方法中增加架构评审；
同行评审方法中增加重构、结对编成
验证方法的举例中增加了“架构评审、架构实现与架构设计的一致性检查”
验证方法的举例中增加了“持续集成（用于早期识别集成问题的敏捷方法）”
同行评审数据分析举例时增加“与缺陷相关的用例、与缺陷相关的客户或最终用户”
2 敏捷开发
在Agile环境中，由于客户的参与和频繁发布版本，验证和确认两个过程需要交替进行，互相支持。例如一个缺陷可能导致一个原型或一个早期发布的版本失效。反之，尽早的持续的确认有助于帮助验证过程应用于正确的产品。验证和确认过程能确保用系统化的方法选择工作产品进行评审和测试，有助于尽早识别缺陷。产品越复杂，越需要用系统化的方法验证需求、解决方案及其最终使用之间的一致性和兼容性
11 VAL (Validation) —— 确认
在sp2.2“分析确认结果”中增加子实践：提供信息说明确认过程中的（遗留）缺陷如何解决，并发起纠正措施。
嘿嘿，格式好规范...顶... 回复
2楼
这人很郁闷
的帖子
页:
[1]