CMM中的需求管理与需求开发
CMM简介软件能力成熟度模型
CMM的五个等级
1. 初始级：软件过程的特点是无序的，甚至是混乱的。 几乎没有什么过程是经过妥善定义的，成功往往依 赖于个人或小组的能力。
2. 可重复级：建立了基本的项目管理过程来跟踪成本、 进度和功能特性。制定了必要的过程纪律，能重复 早先类似应用项目取得的成功。
3. 已定义级：已将管理和工程活动两方面的软件过程 文档化、标准化，并综合成该机构的标准软件过程。 所有项目均使用经批准、剪裁的标准软件过程来开 发和维护软件。
4. 已管理级：收集对软件过程和成品质量的详细度量 值，对软件过程和产品都有定量的理解和控制。
5. 优化级：过程的量化反馈和先进的新思想、新技术 促使过程不断改进C。MM简介软件能力成熟度模型
关键过程域
指明为了改进其软件过程组织应重点关注的区 域。识别出为了达到某个成熟度等级所必须着 手解决的问题。
SEI：美国卡耐基梅隆大学的软件工程研究 院产品
SEI：为美国联邦政府评估软件供应商能力，于 1986年开始研究的模型，于1993 年推出CMM 1.1版。
CMM 1.1版：是目前世界上比较流行和通用的CMM 版本。
新研究：
CMMI ( Integration ) P-CMM ( People ) SACMM ( 软件获取CMM )
CMM定义：对于软件组织在定义、实现、度量、控 制和改善其软件过程中各个发展阶段的描述。这个模 型便于确定软件组织的现有过程的能力和查找软件质 量及过程改进方面最关键的问题，从而为选择过程改 进战略提供指南。
CMM简介软件能力成熟度模型
SEI：Software Engineering Institute
组织过程定义的目标是，开发和维护一组可用的能提高项目软件 过程整体效能的软件过程资源集合，并为在定量过程管理中确定 有意义的数据提供基础，这些资源提供了一组稳定的准则，并通 过诸如培训等机制使其制度化。
需求开发与需求管理指引
需求开发与需求管理指引第1章C M M I综述·2·第1章 CMMI综述1.1CMMI简介 (4)1.1.1 CMMI发展简史 (4)1.1.2 CMMI的过程域 (5)1.1.3 CMMI的两种表⽰法 (6)1.2CMMI阶段式表⽰法 (7)1.2.1 成熟度等级L1：初始级的特征 (8)1.2.2 成熟度等级L2：已管理级的特征 (9)1.2.3 成熟度等级L3：已定义级的特征 (9)1.2.4 成熟度等级L4：量化管理级的特征 (9)1.2.5 成熟度等级L5：持续优化级的特征 (10)1.3CMMI连续式表⽰法 (10)1.3.1 能⼒等级0-不完整级的特征 (12)1.3.2 能⼒等级1-已执⾏级的特征 (12)1.3.3 能⼒等级2-已管理级的特征 (12)1.3.4 能⼒等级3-已定义级的特征 (13)1.3.5 能⼒等级4-量化管理级的特征 (13)1.3.6 能⼒等级5-持续优化级的特征 (14)1.4过程域的部件及解释 (14)1.4.1 必需部件 (15)1.4.2 期望部件 (15)1.4.3 信息部件 (16)1.5CMMI评估 (17)1.5.1 CMMI评估要求 (17)第1章 CMMI综述.3.1.5.2 CMMI标准评估⽅法SCAMPI (17) 1.5.3 CMMI评估考虑事项 (18)1.6CMMI和CMM的⽐较 (19)1.6.1 CMMI与CMM的模型⽐较 (19)1.6.2 CMMI 与CMM 过程域⽐较 (19)1.6.3 CMMI 与CMM评估⽅法⽐较 (21)1.7CMM/CMMI在中国 (21)·4·第1章 CMMI综述1.1 CMMI简介1.1.1 CMMI发展简史1981年，美国卡内基梅隆⼤学软件⼯程研究所（SEI），应美国联邦政府的要求开发了⼀种⽤于评价软件承包商能⼒并帮助其改善质量的⽅法。
Watts Humphrey将成熟框架带到了SEI并增加了成熟度等级的概念，将这些原理应⽤于软件开发，发展成为软件过程成熟度框架，它提供了⼀个评估软件开发过程的管理以及⼯程能⼒的标准。
CMM中的需求管理与需求开发
需求管理（Requirements Management ）是属于CMM2中的过程域，简称为REQM ，需求开发（Requirements Development ）是CMM3中的过程域，简称RD 。
这两个过程域是CMMI 体系中关于需求的全部内容，下面分别对这两部分进行介绍。
本文对CMM 的一些基础知识、基础术语不再介绍。
需求管理与需求开发的分界线：市场营销用户需求管理层需求开发需求管理市场营销管理层项目环境项目变更 大家可以这样理解，需求管理是指对需求变更的管理、对需求的跟踪，而获取需求、定义需求则属于需求开发部分。
需求管理在CMMI 中，需求管理的目标定义为：a. 把软件需求建立一个基线供软件工程和管理使用。
b. 软件计划、活动和工作产品同软件需求保持一致。
更高的目标：软件需求的复用需求管理的原则和方法a. 必须与需求工程的其他活动紧密整合b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的c. 只要需求变化了，需求变更的影响就必须被评估d. 需求必须分优先级e. 需求一定要分类管理需求管理的主要工作：特定目标和特定实践特定目标●管理需求管理需求并识别需求与项目计划和工作产品之间的差异。
●SP 1.1 取得需求理解●SP 1.2 取得需求承诺●SP 1.3 管理需求变更●SP 1.4 维护需求的双向追溯性●SP 1.5 识别项目工作与需求间的差异REQM特定目标的关系SP 1.1 取得需求理解SP 1.1 和需求提出者一同来了解需求。
l 识别出谁是需求的提供者l 识别出需求的接受标准：a. Clearly and properly stated得到清晰和恰当的定义b. Complete完整的c. Consistent with each other相互一致的d. Uniquely identified得到唯一标识的e. Appropriate to implement适宜实现f. Verifiable (testable)可以验证（测试）g. Traceable可追溯l 分析需求，确保符合已建立的准则。
CMMI和CMM区别
CMMI和CMM区别CMMI的全称为：Capability Maturity Model Integration,即能力成熟度模型集成.自从1994年SEI正式发布软件CMM以来,相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。
虽然这些模型在许多组织都得到了良好的应用，但对于一些大型软件企业来说，可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况.这时他们就会发现存在一些问题,其中主要问题体现在：■不能集中其不同过程改进的能力以取得更大成绩；■要进行一些重复的培训、评估和改进活动，因而增加了许多成本；■不同模型对相同事物说法不一致,或活动不协调，甚至相抵触.于是，希望整合不同CMM模型的需求产生了.1997年，美国联邦航空管理局（FAA)开发了FAA-iCMMSM（联邦航空管理局的集成CMM)，该模型集成了适用于系统工程的SE-CMM、软件获取的SA—CMM和软件的SW—CMM三个模型中的所有原则、概念和实践。
该模型被认为是第一个集成化的模型。
CMMI与CMM最大的不同点在于：■CMMISM-SE/SW/IPPD/SS 1.1版本有四个集成成分,即:系统工程(SE)和软件工程(SW)是基本的科目，对于有些组织还可以应用集成产品和过程开发方面(IPPD）的内容，如果涉及到供应商外包管理可以相应地应用SS(Supplier Sourcing）部分。
■CMMI有两种表示方法，一种是大家很熟悉的，和软件CMM一样的阶段式表现方法，另一种是连续式的表现方法.这两种表现方法的区别是:阶段式表现方法仍然把CMMI中的若干个过程区域分成了5个成熟度级别,帮助实施CMMI的组织建议一条比较容易实现的过程改进发展道路。
而连续式表现方法则通过将CMMI中过程区域分为四大类：过程管理、项目管理、工程以及支持。
对于每个大类中的过程区域，又进一步分为基本的和高级的。
这样，在按照连续式表示方法实施CMMI的时候，一个组织可以把项目管理或者其他某类的实践一直做到最好,而其他方面的过程区域可以完全不必考虑。
CMMI体系介绍
CMMI体系介绍
质量控制中心：董宝国 2011年4月
大纲
1 行业背景
2 MMI前世今生 3 CMMI基本框架
4
CMMI过程改进成果与经验
5
CMMI改进规划
6
问题交流
一 行业背景
截止2009年末，世界CMM/CMMI认证企业数量
CMM/CMMI认证数量
882, 16% 1200, 22%
09年度
进度偏差 成本偏差
某公司实施CMMI3过程改进三年数据对比
7% 3%
10年度
四 CMMI 改进经验分享-最佳实践
1. 建立组织资产库
1. 体系文件库（项目规范及模板文件） 2. 度量数据库（公司执行历史项目的数据汇总分析） 3. 风险库（成功的和失败的风险教训） 4. 经验库（历史项目文档；优秀样例；培训教材库；知识库） 2. 项目分类管理 3. 项目管理过程可视化、数据化，拒绝“讲故事”，用数据说话。 4. 项目绩效考核 5. 挣值管理 6. 代码走查、原型+用例描述需求…………
三 CMMI基本框架
1. CMMI的表现形式 2. CMMI的成熟度等级 3. CMMI的架构介绍 4. CMMI的评估方法
三 CMMI基本框架－表现形式
CMMI的两种表现形式： 阶段式Staged：用成熟度级别 连续式Continuous：用能力级别
CMMI的两种级别： Capability levels：用于衡量每个过程域的过程改进 Maturity levels：用于衡量整个组织的过程能力和组织成熟度
四 CMMI 改进经验分享
成功项目4个要素
清晰预算 需求明确 进度要求 交付质量 采纳变更
cmm是什么意思
cmm是什么意思CMM是指能力成熟度模型，其它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。
CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。
此外还是化妆品的名字。
实施CMM的必要性。
软件开发其中最关键的问题在于软件开发组织不能很好地管理其软件过程，从而使一些好的开发方法和技术起不到预期的作用。
而且项目的成功也是通过工作组的杰出努力，所以仅仅建立在可得到特定人员上的成功不能为全组织的生产和质量的长期提高打下基础，必须在建立有效的软件如管理工程实践和管理实践的基础设施方面，坚持不懈地努力，才能不断改进，才能持续地成功。
软件质量是一模糊的、捉摸不定的概念。
我们常常听说某某软件好用,某某软件不好用。
某某某软件功能全、结构合理,某某某软件功能单一、操作困难。
这些模模糊糊的语言不能算作是软件质量评价，更不能算作是软件质量科学的定量的评价。
软件质量，乃至于任何产品质量，都是一个很复杂的事物性质和行为。
产品质量，包括软件质量，是人们实践产物的属性和行为，是可以认识，可以科学地描述的。
可以通过一些方法和人类活动，来改进生活质量。
实施CMM是改进软件质量的有效方法，控制软件生产过程、提高软件生产者组织性和软件生产者个人能力的有效合理的方法软件工程和很多研究领域及实际问题有关，主要相关领域和因素有，需求工。
理论上，需求工程是应用已被证明的原理、技术和工具，帮助系统分析人员理解问题或描述产品的外在行为。
软件复用。
定义为利用工程知识或方法，由一已存在的系统，来建造一新系统。
这种技术，可改进软件产品质量和生产率。
还有软件检查、软件计量、软件可靠性、软件可维修性、软件工具评估和选择等。
CMMI体系概述
CMMI体系概述CMMI（Capability Maturity Model Integration）是一个被广泛采用的过程改进框架和评估模型。
它提供了一种尝试和提高组织内软件和系统产品开发、维护和管理过程质量和效率的方法。
CMMI通过一个层次结构来组织和描述这些过程，并提供了一种评估和改进这些过程的方法。
CMMI最初是由美国国防部为了提高其软件和系统产品开发过程的能力而开发的。
该模型最早是以CMM（Capability Maturity Model）的形式出现，它被广泛应用于软件开发领域。
然而，随着对软件开发以外过程的需求增加，CMMI随后被引入和扩展到其他领域，如系统工程、工程、产品开发、供应链管理等。
CMMI采用了一个层次结构的方法来描述和评估组织的过程能力。
这个层次结构由五个不同的成熟度等级组成，从最初的“初始”级到最高的“优化”级。
这些级别反映了组织过程的能力水平和成熟度。
在每个成熟度等级中，CMMI描述了一系列的过程领域和实践，这些实践描述了在组织中实现成熟程度所需的活动和任务。
这些实践可以被组织用来评估并改进其过程的质量和效率。
CMMI的主要目标是帮助组织提高其过程能力，并在产品开发、维护和管理过程中实现更高的质量、效率和可靠性。
通过采用CMMI，组织可以更好地理解和管理其过程，提高与合作伙伴的协作和沟通，在市场上增强竞争力。
由于其广泛的应用和认可，CMMI已经成为许多组织在过程改进和能力评估方面的首选模型。
在一些领域，如国防、航空航天、金融和电信，CMMI已经成为实施组织过程改进的行业标准。
尽管CMMI在过程改进中有很多好处，但它也面临着一些挑战和批评。
有些人认为，CMMI过于复杂和繁琐，实施起来需要大量的时间和资源，特别是对于小型企业来说。
此外，一些人也认为，CMMI过于侧重于过程和文档，而忽视了创新和灵活性。
总的来说，CMMI是一个广泛应用的过程改进框架和评估模型，它提供了一种帮助组织提高过程能力和质量的方法。
CMM介绍与关键过程域说明
CMM介绍与关键过程域说明CMM（Capability Maturity Model）是一种用于管理和评估组织软件开发能力的框架，旨在帮助组织提高其软件开发过程的成熟度，从而提高软件质量和效率。
CMM通过一系列定义明确的关键过程域来描述一个成熟的软件开发组织的特征和实践。
以下是关于CMM和关键过程域的详细介绍。
CMM是由美国软件工程研究所（SEI）于1980年代末开发的。
它最初是为了衡量美国国防部软件供应商的能力而设计的。
CMM在软件工程领域的可行性和实用性被广泛认可，并在全球范围内被广泛采用。
CMM的主要目标是帮助组织改进其软件开发过程的效率和质量，并推动软件工程实践的采用。
CMM采用了一个阶梯式模型，包括五个不同的成熟度级别，从初始级别到最高级别分别是：初始级别、可重复级别、已定义级别、已管理级别和优化级别。
每个级别都有一组关键过程域，这些关键过程域是用于衡量和评估组织软件开发能力的基础。
下面是对每个成熟度级别和相关关键过程域的详细说明：1. 初始级别（Level 1 - Initial）在初始级别，组织的软件开发过程是不可预测的，不受控制的。
该级别缺乏组织和过程的可见性和管理。
没有明确的目标和计划，开发活动主要靠个别开发人员的技能和经验来完成。
2. 可重复级别（Level 2 - Repeatable）在可重复级别，组织开始建立一些基本的项目管理和过程管理能力。
关键过程域包括需求管理、配置管理、项目计划和追踪、软件质量保证等。
目标是确保软件开发过程的可重复性和可控性。
3. 已定义级别（Level 3 - Defined）在已定义级别，组织建立了一套标准化的软件开发过程，并且这些过程已经在组织范围内得到了共享和理解。
关键过程域包括需求开发、软件设计、软件构建、软件测试等。
目标是确保软件开发过程的一致性和稳定性。
4. 已管理级别（Level 4 - Managed）在已管理级别，组织通过定量的管理和度量，对软件开发过程进行管理和优化。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需求管理（Requirements Management ）是属于CMM2中的过程域，简
称为REQM ，需求开发（Requirements Development ）是CMM3中的过程域，简称RD 。
这两个过程域是CMMI 体系中关于需求的全部内容，下面分别对这两部分进行介绍。
本文对CMM 的一些基础知识、基础术语不再介绍。
需求管理与需求开发的分界线：
市场营销
用户需求
管理层
需求开发
需求管理
市场
营销
管理层需求变更项目环境
项目变更 大家可以这样理解，需求管理是指对需求变更的管理、对需求的跟踪，而获取需求、定义需求则属于需求开发部分。
需求管理
在CMMI 中，需求管理的目标定义为：
a. 把软件需求建立一个基线供软件工程和管理使用。
b. 软件计划、活动和工作产品同软件需求保持一致。
更高的目标：
软件需求的复用
需求管理的原则和方法
a. 必须与需求工程的其他活动紧密整合
b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的
c. 只要需求变化了，需求变更的影响就必须被评估
d. 需求必须分优先级
e. 需求一定要分类管理
需求管理的主要工作：
特定目标和特定实践
特定目标
●管理需求
管理需求并识别需求与项目计划和工作产品之间的差
异。
●SP 1.1 取得需求理解
●SP 1.2 取得需求承诺
●SP 1.3 管理需求变更
●SP 1.4 维护需求的双向追溯性
●SP 1.5 识别项目工作与需求间的差异
REQM特定目标的关系
SP 1.1 取得需求理解
SP 1.1 和需求提出者一同来了解需求。
l 识别出谁是需求的提供者
l 识别出需求的接受标准：
a. Clearly and properly stated得到清晰和恰当的定义
b. Complete完整的
c. Consistent with each other相互一致的
d. Uniquely identified得到唯一标识的
e. Appropriate to implement适宜实现
f. Verifiable (testable)可以验证（测试）
g. Traceable可追溯
l 分析需求，确保符合已建立的准则。
l 与需求提供者达到需求共识，以使项目成员能承诺它们SP1.2 获取对需求的承诺
SP1.2 取得项目成员对需求的承诺。
●评估需求对现有承诺的影响。
需求变更或新需求发生时，评估它们对项目成员的影
响。
●协商并记录承诺。
在项目成员对需求或需求改变承诺之前，对现有承诺
的改变应先进行协商。
●承诺的时间点：
a. 需求刚建立时
b. 需求变更时
产出物
●需求影响评估
●需求和需求变更承诺的纪录
●项目组成员工作任务书
SP 1.3 管理需求变更
SP 1.3 当需求在项目执行期间逐渐开发时，管理
需求的变更。
●在项目执行期间，造成需求变更的原因很多：
a. 需要改变
b. 工作进行中产生新需求
●提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。
对项目
开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价。
如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。
配置变更委员会CCB
●CCB是授权进行正式基线变更的机构
✓例如客户需求、设计基线。
●职能：
✓确保变更被分类以及被评估
✓评审和批准变更
✓确保只有被批准的变更得到实施
✓决定需要实施的变更的优先级
●变更控制活动必须在整个项目中具有可视性
●CCB成员可能包括：项目经理，配置管理员，质量保证人员，开发人员代表，
客户代表。
需求变更的阶段
●提交
●评估
●审批
●实施
●验证
●关闭
产出物
●需求变更申请表
●需求变更汇总表
SP 1.4 维护需求的双向追溯性
●维护需求与项目计划和工作产品间的双向追溯性。
●产出物：
需求跟踪矩阵
需求跟踪矩阵的主要作用
RTM的作用
A、验证需求的可实现性、可测试性
B、进行需求变更的影响分析
C、维护阶段，管理需求的变更
需求跟踪矩阵分为：纵向跟踪和横向跟踪
应该建立哪些需求跟踪矩阵？
●在SEI的调查中达成的基本共识是：纵向跟踪是必须的，如果没有，则REQM
SP1.4无法通过。
●对于纵向跟踪矩阵：
必需的：
✓客户需求与产品需求的跟踪
✓产品需求与测试用例的跟踪
✓100%的接口需求
✓全局性需求
✓核心需求
并非必需的：
✓性能需求
✓不影响系统架构的功能需求
需求跟踪矩阵由谁来建立？
●有多个角色参与建立RTM：
a. 需求开发人员
b. 设计人员
c. 测试用例的编写人员
d. PPQA
RTM是否纳入基线管理？
●RTM要纳入基线管理。
●纳入基线后，每次变更都要申请，RTM的变更一般是和其他配置项的变更一
起申请，很少单独申请变更RTM，除非RTM有错误。
●如何简化RTM的工作？
●由于在RTM中，需求可能有很多项，设计、测试用例、代码等都有多项，所
以建立和维护RTM的工作量还是比较大、比较烦琐。
对于变化频繁的项目，更是如此。
在实践中，为了简化该RTM的建立与维护工作，有的企业仅仅通
过需求与设计、代码、测试用例的编号来实现跟踪，如需求为：r1,r2,
……等编号，而设计的编号为：r1-d1,r1-d2,…….,测试用例的编号为：r1-t1,r1-t2等等。
需要注意的是需求与它们之间是多对多的关系，仅通过编号是无法实现这种关系的。
如果不借助DOORS之类的需求管理工具，一般只能通过EXCEL来维护RTM，工作量就
●是比较大。
要简化，就要平衡管理的投入与产出。
●当然也可以考虑增大需求、设计、代码、测试用例的颗粒度大小，但是那样
RTM的作用就打了折扣，还是一个平衡问题。
SP1.5 确认项目工作和需求间的差异
主要活动：
●评审项目计划、活动和工作产品是否与需求和需求变更相符。
●识别差异来源及其理由。
●当需求基线有变动时，识别有关计划和工作产品所需的变更。
●启动纠正措施。
识别差距的时机？
●评审时
●变更时
●日常工作中
识别出的不一致问题要有记录，并跟踪问题的关闭需求管理我们需要客户方如何做。
●了解乙方需求变更流程，并与乙方就此流程达成一致
●指定专人负责需求变更
●内部形成一个需求变更流程
●针对内部提交的需求变更，在提交乙方之前横向分析对业务的影响
●在提交乙方之前，内部达成一致意见
●需求变更必将导致乙方开发成本增加，为保证项目成功，必要时追加合同资
金
● .
●
●。