下载文档原格式
Introduction to Process Area of CMMI-DEV®®Capability Maturity Model ® and CMMI ® are registered marks of SEICapability Maturity Model Integration (CMMI ) Version 1.2CMMI For Development Process Area介绍目的需求管理的目的是对项目产品及产品组件的需求进行管理，同时确定这些需求与项目计划和产品之间的不一致之处。
关注点附加在项目上的需求与RD,TS紧密联系并同步执行。
当项目从需求提供者获取需求时，应与其一起审核，部分需求管理需要记录需求变更及其理由并维护原始需求与所有产品和产品组件需求之间的双向可溯性特定目标/实践与通用目标/实践SG 1 管理需求SP 1.1 获得对需求的理解SP 1.2 获得对需求的承诺SP 1.3 管理需求变更SP 1.4 维护秀的双向跟踪SP 1.5 识别项目产品与需求的不一致GG2制度化已管理的过程GG3制度化已定义的过程GG4制度化已量化的过程GG5制度化优化的过程。
目的PP的目的在于建立并维护用以定义项目各项活动的计划。
关注点§以及识别和分析项目风险。
§根据项目的进展情况对项目计划进行修订实践‚SG1 项目估算§SP1.1 估计项目的范围§SP1.2 工作产品与任务属性的估算§SP1.3定义项目的生命周期SP1.4 判定工作量和成本的估值‚SG2 制定项目计划§SP2.1 编制预算和进度§SP2.2 识别项目风险§SP2.3 规划资料管理§SP2.4 规划项目资源§SP2.5 计划所需的知识和技能§SP2.6 策划相关方的介入§SP2.7 创建项目计划‚SG3 获得实现计划的承诺§SP3.1 审查影响项目的各种计划§SP3.2 调整工作与资源配置SP3.3 获得计划承诺‚GG2制度化已管理的过程GG3制度化已定义的过程GG4制度化已量化的过程GG5制度化优化的过程。
CMMI V 1.2 的特定目标和实践2.1 CMMI2级过程域：需求管理* 目的：管理项目的“产品需求和构件需求”，以及识别这些需求与项目计划、工作成果的不一致之处。
* 特定目标(SGl)：需求已经受管理，并且识别出需求与项目计划不一致之处。
需求管理过程域的特定目标(SG)和特定实践(SP)见表2-1。
表2-1 需求管理过程域的特定目标和特定实践2.1.1 SG 1管理需求2.1.1.1 SP l.1获得对需求的理解需求管理过程域的特定实践SP l.1是“获得开发者和提供者对需求的共同理解”。
随着项目的进展，为了避免需求的蔓延或遗漏，要建立一些准则，用以指明接受需求的适当渠道或正式来源。
接受需求并对需求进行分析，这些活动与需求提供者一起进行，以确保双方对需求的含义达成共识。
对需求的分析和对话的结果是达成共识的需求集合。
典型工作成果：》 用于识别“合适的需求提供者”的准则。
》 评价和接受需求的准则。
》 依照准则进行分析的结果。
》 达成共识的需求集合。
2.1.1.2 SP 1.2 获得对需求的承诺需求管理过程域的特定实践SPl ．2是“获得项目参加者对需求的承诺”。
即使以前某个活动与需求提供者达成了对需求的一致理解，但在具体实施时，还需要与实施这些活动的人员，就需求达成一致，并得到他们的承诺。
在整个项目开展过程中，需求会发生演变，特别在“需求开发”和“技术方案”过程域中。
随着需求的演变，受该活动影响，项目参与者需要对当前的已批准的需求作出承诺，以及对受影响的项目计划、活动和工作成果作出相应的变更。
典型工作成果：》 需求影响的评估。
》 记录“需求和需求变化”的承诺(形成文档)。
2.1.1.3 SP 1.3 管理需求的变更需求管理过程域的特定实践SP l.3是“管理随着项目进展而发生的需求变更”。
在项目开发期间，需求会由于各种原因而发生变更，将会产生一些附加的需求，也许不得不对现行的需求作出变更以满足客户要求。
产品经理应该了解的CMMI模型编辑导读：产品经理学习CMMI，一方面是学习CMMI解决软件问题的方法论，另一方面是了解主流的软件开发流程，方便协调产品和项目开发。
本文作者从CMMI 的基本概念出发，对CMMI的级别和发展现状展开了详细的介绍，与大家分享，希望通过此文能够加深你对CMMI的了解。
01 基本概念1.1 过程改进在软件开发中，约束软件项目的三个要素是质量、进度和成本，被称为软件开发铁三角，软件开发总是在这三个要素中妥协平衡，不时要抉择保哪个牺牲哪个，不断在刀尖上跳舞。
而决定质量的要素又有三个：人、过程和技术，其中CMMI 主要关注过程的改进。
因为CMMI有一个基本的假设前提：产品的质量很大程度上受影响于所使用的开放与维护过程的质量。
所以为了改进产品质量，需要改进过程质量，称为过程改进。
1.2 CMMI的定义CMMI, Capability Maturity Model Integration，能力成熟度模型集成。
CMMI是美国国防部发起并资助的一个项目，由卡内基梅隆大学软件工程研究所（SEI）开发。
CMMI是一种过程改进模型。
CMMI是业界过程改进的最佳实践集合。
CMMI关注于改进组织内部的过程，描述了从随意、不成熟的过程到提高了质量与有效性的、有秩序、成熟的过程的演进道路。
1.3 CMMI模型CMMI 1.3分为三种模型：CMMI-DEV开发模型（应用最广）、CMMI-SVC服务模型和CMMI-ACQ采购模型。
它们有公用的一些过程域，也有特有的一些过程域。
CMMI的最新版本为2.0，但相关资料非常少，官网购买CMMI-DEV 2.0指南需要150美元。
1.4 过程域PACMMI-DEV-v1.3为例，包含22个PA，分为过程管理类、项目管理类、工程类和支持类4类：过程管理5个PA：OPD组织级过程定义、OPF组织级过程关注、OPM组织级绩效管理、OPP组织级过程性能、OT组织级培训。
CMMI扫盲1⾄5级简述CMMI扫盲摘要：CMMI全称是Capability Maturity Model Integration，CMMI是个好东西来的，但⾏内⼈⼠对她的认识并不全⾯，甚⾄有种种的误解。
尽管⽹上有很多CMMI相关介绍，但⼀般都是⽐较苦涩难懂的。
本⽂将⽤⽣动通俗的语句，让⼤家初步看清楚CMMI的真⾯⾯孔。
CMMI是什么东西？CMMI英⽂全称是Capability Maturity Model Integration，直接翻译就是能⼒成熟度模型，直接看这⼏个中⽂字，你还是没有办法搞清楚CMMI是什么东西的。
⼤家可能在⽹上见过很多《成功⼈⼠的七个习惯》（可能还有很多类似的名字）的⽂章吧？有⼈总结了成功⼈⼠的成功的原因，总结出他们的习惯，如果我们也能具备这些习惯，那么我们也很可能成为成功⼈⼠。
类似的，CMMI可以看作是成功企业如何做好软件的⼀些习惯、做法、准则等的集合，是如何做好软件的最佳实践的集合。
如果企业也能按照CMMI的要求做好，那么企业就很可能成为成功的企业。
CMMI⾥⾯所有的要求，都是来⾃于成功企业的最佳实践的，她的先进性我们不必怀疑，如果我们没有做好，那不是CMMI本⾝的问题，⽽是我们⾃⼰没有理解好或者是没有执⾏好的原因。
说到CMMI，就不可避免会提到另外3个字母SEI，SEI全称是Software Engineering Institute 的全称，直译就是软件⼯程研究所，是美国的⼀所⼤学（卡内基梅隆⼤学CMU）与美国国防部合作成⽴的，CMMI标准就是他们搞出来的。
CMMI⽬前最新版本是V1.2，如果你是现在才开始了解CMMI的，那么你完全没有必要去搞清楚V1.1与V1.2的差别，更加没有必要去⽐较CMM与CMMI的差别，直接了解CMMI V1.2就可以了，你只需要知道CMM是CMMI的前⾝，⽽CMMI V1.1虽然⽐CMM要新很多，但现在已经不⽤了。
现在在互联⽹上还有很多⽐较CMM与CMMI的⽂章的，除⾮你很想了解或者你有很多时间，建议不必去看这些内容。
Generic Goal●删除了各个PA的GG部分描述，汇总到"Generic Goals and Generic Practices"章节统一描述，在不同的GP中，增加针对不同PA的明细描述。
●全文删除原关于IPPD的附加描述。
Causal Analysis Resolution（CAR）●SG1："Determine Causesof Defects"->"Determine Causes of Selected Outcomes"SP1.1："Select Defect Data for Analysis"->"Select Outcomes for Analysis"注：将缺陷（Defect）改为选定结果（Outcome），扩大CAR的范围（有些虽是统计缺陷，但却是好的结果）●SG2："Address Causes of Defects"->"Address Causesof Selected Outcomes"SP2.2："EvaluatetheEffectofChanges"->"EvaluatetheEffectofImplementedActions"SP2.3："Record Data"->"Record Causal Analysis Data"注：特定实践的描述更清晰，并联系上下文。
Configuration Management（CM）●SG、SP无变化DecisionAnalysisResolution（DAR）●SP1.5："Evaluate Alternatives"->"Evaluate Alternative Solutions"注：描述上的精确Integration Project Management（IPM）●增加SP1.6："Establish Teams"，建立项目团队（类似原SG3中的SP3.4Establish Integrated Teams）●删除原IPPD附加的SG3Measurement Analysis（MA）●SG、SP无变化●SP1.2：增加了一个表Example Measurement Relationships，度量联系示例（GQIM）Organizational Process Define（OPD）●增加SP1.7 Establish Rules and Guidelines for Teams（建立团队的规则与指导方针）●类似于原SG2中的SP2.2 Establish Rules and Guidelines for Integrated Teams●删除原IPPD附件的SG2Organizational Process Focus（OPF）●SG2："Plan and Implement Process Improvements"->"Plan and Implement Process Actions"措词更严谨，且对应SP的Process Action Plans●SG3："Deploy Organizational Process Assets and Incorporate Lessons Learned"->"Deploy Organizational Process Assets andIncorporate Experiences"把“教训”改成“经验”Organizational Performance Management（OPM）●OID（组织革新部署）->OPM（ORGANIZATIONAL PERFORMANCE MANAGEMENT组织性能管理）●增加SG1：Manage Business Performance（管理商业性能）●增加一个SG，细化描述OID的源头（基于组织商业目标/性能），并明确要求使用统计或者其它量化技术（基本还是统计）管理商业性能，理解过程性能的不足。
SP1.1 Maintain Business Objectives（管理商业目标，基于组织商业战略和实际性能结果）SP1.2 Analyze Process Performance Data（分析过程性能数据，确定是否符合商业目标）SP1.3 Identify Potential Areas for Improvement（识别潜在的改进领域，以助于满足商业目标）注1：CMMI模型的改进（3级以下、4/5级），应都是源于组织商业目标，在OPM中增加该SG，是强调了量化技术及与OPP过程性能的联系；●SG2SP2.1 "Collect and Analyze Improvement Proposals"->"Elicit Suggested Improvements"细分SP2.1，把原先的“收集分析”拆成2个特定实践，在SP2.1中，指抽取出改进建议，加以分类（渐进式、创新式），并对创新式进行调研SP2.2 "Identify and Analyze Innovations"->"Analyze Suggested Improvements"简化了创新式改进的识别与分析描述（合并到SP2.1），变为通用的过程改进建议分析（原SP2.1的后半部分子实践），最终选定改进点SP2.3 "Pilot Improvements"->"Validate Improvements"将Pilot（试行）改成Validate（确认）,放松对改进建议评估的要求（模型认为Pilot是评估重大变化、高风险、创新式改进的一个严格的试点过程，但并不是所有的改进都需要Pilot。
）SP2.4 "Select Improvements for Deployment"->"Select and Implement Improvements for Deployment"增加的"Implement"是在子实践中，增加了识别改进点的差异，更新组织过程资产，为SG3的部署做准备；●SG3SP3.3 "Measure Improvement Effects"->"Evaluate Improvement Effects"明确是采用统计或者其它量化技术来评估改进效果，而非原来的度量描述Organizational Process Performance（OPP）●SP1.1 "Select Processes"->"Establish Quality and Process Performance Objectives"●SP1.2 "Establish Process-Performance Measures"->"Select Processes"●SP1.3 "Establish Quality and Process-Performance Objectives"->"Establish Process Performance Measures"将建立QPPO提前，基于目标选择过程、确定度量●SP1.4 "Establish Process-Performance Baselines"->"Analyze Process Performance and Establish Process PerformanceBaselines"增加分析的子实践，明确是一个分布或者结果范围Organizational Training（OT）●SG2："Provide Necessary Training"->"Provide Training"提供不限于Necessary的培训需求Product Integration（PI）●SG1SP1.1 "Determine Integration Sequence"->"Establish an Integration Strategy"产品集成策略范围大于集成顺序，增加了对产品集成准备活动的要求Project Monitoring and Control（PMC）●SG、SP无变化Project Planning（PP）●SG1SP1.3 "Define Project Lifecycle"->"Define Project Lifecycle Phases"SP1.4 "Determine Estimates of Effort and Cost"->"Estimate Effort and Cost"●SG2SP2.3 "Plan for Data Management"->"Plan Data Management"SP2.4 "Plan for Project Resources"->"Plan the Project’s Resources"SP2.5 "Plan for Needed Knowledge and Skills"->"Plan Needed Knowledge and Skills"总体描述的精炼和清晰Process and Product Quality Assurance（PPQA）●SP1.2 "Objectively Evaluate Work Products and Services"->"Objectively Evaluate Work Products"取消对“服务”的审查评估●SP2.1 "Communicate and Ensure Resolution of Noncompliance Issues"->"Communicate and Resolve Noncompliance Issues"描述的精炼和清晰Quantitatively Project Management（QPM）●SG1 "Quantitatively Manage the Project"->"Prepare for Quantitative Management"可理解为量化项目管理计划（定目标、选过程、选监控关键子过程、选择分析技术），将具体量化项目管理移到SG2；SP1.3 "Select the Subprocesses that Will Be Statistically Managed"->"Select Subprocesses and Attributes"不特定统计化管理的子过程，但是选择的子过程与属性将用于SP2.1监控子过程性能（采用统计化或者其它量化方式）SP1.4 "Manage Project Performance"->"Select Measures and Analytic Techniques"●SG2 "Statistically Manage Subprocess Performance"->"Quantitatively Manage the Project"●把子过程性能作为管理项目性能的一个特定实践SP2.1 "Select Measures and AnalyticTechniques"->"Monitor the Performance of Selected Subprocesses"原SP2.1提到SG1中；原SP2.3提前到SP2.1，并将原SP2.2合并到该特定实践中。
