下载文档原格式
1、 CMMI阶段式的基本结构从CMM演变而来，但是CMMI的结构更加的形式化和精致，也更加的复杂，尤其为了保证连续式和阶段式的同一性，更加增加了结构的理解难度。
2、 CMMI强调了对需求的管理，有两个过程域说明对需求的控制：需求管理REQM、需求开发RD。
而在CMM中只有一个关键过程域：需求管理RM以及软件产品工程SPE中的一个实践来说明对需求的管理和控制。
3、 CMMI加强了对工程过程的重视，提供了更加细致的要求和指导，而CMM 中却只有一个关键过程域SPE来进行要求和指导。
4、 CMMI强调了度量，并且从项目的早期就已经进行了度量，在阶段式中CMMI二级有一个过程域：度量和分析；而在CMM中没有专门的要求和指导，度量和分析的要求分布在每个关键过程域中。
5、 CMMI比CMM更加强调了对风险的管理，在CMM中风险只是“项目策划”和“集成软件管理”中的一个活动，而在CMMI中风险管理作为一个单独的过程域。
6、 CMM中的一个关键过程域“组间协调”IC在CMMI中地位下降，只是作为“集成化项目管理”IPM中的一个目标。
7、 CMM中的关键过程域“同行评审”PR，在CMMI中得到了更高的抽象；对应CMMI的“验证”VER，说明了对产品进行相应的QC活动。
（同行评审本身就是一种QC活动）8、 CMMI的共同特性中，没有了度量（ME），这些度量内容被组织起来形成了一个支持过程“度量和分析”。
具体理由如下：度量和分析本身应用的复杂性和它执行的高成本。
在原来的CMM中每个KPA均有单独的度量要求，容易造成“过度度量”，也没有形成对组织级的、统一的度量体系的指导和要求，造成实施中的困难。
例如在CMM中如果一个组织达到了CMM三级，由于各个KPA均要求了度量（ME），实际上已经建立了全组织过程的测量，这和CMM的等级划分思想是有着冲突的。
CMMI改进了这个方面，要求组织从组织级的统一要求出发建立度量体系。
这样的想法也符合过程改进理论的思想；这样组织在实施过程中可以选择必要的过程进行测量，而不是全部过程的测量，从这个意义上，CMMI比CMM降低了对度量的要求和实施难度，但是更加具有全局性和可实施性。
1、CMMI基本介绍1.1、起因和缘由工程环境和过程更加复杂，独立的CMM面对更加复杂化的要求不能适应了。
针对分段工作的弊端（重复返工），工作更加集成化，这样需要集成化的专业知识，也需要集成化的过程。
多种模型的衍生，造成了理解和培训上的困难。
同时多种衍生模型的实践提供了必要的信息和信心，可以建立这样集成的能力程度模型1.2、目标成本效益：减少理解和培训上的成本；改进模型：统一模型利于统筹进行分析和计划；避免封闭的过程改进：过程按照学科单独进行，没有顾及整体效益；交流：跨越部门学科的过程带来更多的交流，从而利于紧密的、有效的、精简的、继承的过程，对过程改进有全局效益统一模型的过程改进（不仅仅是软件过程能力）提供更大的适应性和扩充性，减少冲突和冗余1.3、CMMI框架结构的基本思想CMMI的框架结构基于对对过程和过程改进理论的深刻认识公共性的基础：项目管理和过程管理适用于任何学科如果进行适当的抽象，则工程过程可以直接应用于任何工程形式支持过程对不同学科提供不同的实现，但是目标和实践可以保持不变模型结构思路：根据信息的不同作用进行分类，划分为十二种构件整个模型由此十二种构件组成，并且具备一定的结构每个构件由一个或者多个资料组成整个模型汇编数了千个小的资料模型的不同表示法，就是通过构件的不同结构来体现模型结构的优点：模型由数千个小的资料组成，不同表示法共同使用这些资料这样来确保两种表示法的“等价性”模型通过十二种构件来组织，建立了一个公共的框架容纳未来的内容所有小资料均归属于不同得构件，模型的改进可以通过小资料的改进来实现2、CMMI的构件CMMI建立了一个自动、可扩展的框架，其中可以放入模型集成构件、培训资料、评估资料，确保在已定义规则下可以将更多学科加入该框架。
公共性是完全可以理解的，过程管理和项目管理可以应用于人和学科CMMI具有多个模型，每个模型通过汇编数千个小资料（构件），这些资料存放在数据库中便于统一引用。
SW-CMM/CMMI的探讨一、引言中国进入WTO后，软件企业的国际化进程也随之加快，CMM/CMMI认证在国内的软件企业相当流行，软件企业都希望借此改进研发的开发过程，随着一些大型软件企业完成CMM认证，也为相当多的中小软件企业带来了希望。
那么CMMI 相对于人们熟悉的SW-CMM 有些什么异同？其变化的原因是什么？SW-CMM 到CMMI 的过渡是势在必行的吗？针对这些问题，本文将SW-CMM 与CMMI 从多个方面和不同的层次进行了对比，剖析了其演变的原因，探讨了其发展前景，并对于企业从SW-CMM 到CMMI 的过渡提出了切实可行的建议。
二、CMM概述1．SW-CMM的产生和发展SW-CMM（Software Capability Maturity Model,下称CMM）是由美国卡内基·梅隆（Carnegie-Mellon University）的软件工程所（Software Engineering Institute，下称SEI）提出的一套对软件过程的管理、改进和评估的模式和方法。
CMM最早被应用于美国国防部，用于评估承接军事项目的软件企业的能力。
由于这些军事项目投资巨大，需要一种科学的评估办法对软件企业进行评审，这是CMM最早期的应用。
1991年，SEI正式提出了CMM1.0版本，并应用于商业软件行业中，取得了巨大的成功。
1993年，SEI根据以往的经验，并且广泛听取了行业专家的意见，推出了CMM1.1，这就是我们现在广泛使用的版本。
十几年来，CMM的改进工作一直在持续进行着，按照SEI的计划，CMM 重复级.0版本将于1997年推出，然后经讨论和修改，于1999年发布CMM2.0。
但此版本因为美国国防部的要求而推迟发布。
2．CMM的基本概念过程（Process）：为实现给定目标所执行的一系列操作步骤。
软件过程（Software Process）：指人们用于开发和维护软件及相关产品的一系列活动、方法、实践和革新。
第3章CMM的体系结构CMM（成熟度模型）是由美国国防部的软件工程研究所（SEI）开发的一种评估和改进软件开发组织能力的方法。
CMM采用五个不同的成熟度级别来评估一个软件开发组织的能力水平，以帮助其提高软件开发过程的质量和效率。
CMM的体系结构主要包括五个级别、过程领域和过程目标。
CMM的五个成熟度级别从最低到最高分别是：初始级、重复级、定义级、管理级和优化级。
每个级别都描述了一个软件开发组织在软件开发和管理上的不同水平。
初始级是指组织没有明确的过程，重复级是指组织已经开始重复使用一些成功的过程，定义级是指组织已经定义了一个标准的软件开发过程，管理级是指组织已经能够根据指标进行管理和持续改进，而优化级是指组织不断优化其软件开发过程以适应变化的需求。
CMM的过程领域是指软件开发过程中的六个关键领域，包括需求管理、项目计划和追踪、软件子系统实现、软件测试、集成与确认以及软件交付和维护。
这些领域是软件开发过程中最常见的问题和挑战，CMM通过评估每个领域的能力来指导组织改进其软件开发过程。
每个过程领域都有一组过程目标，这些目标描述了组织在该领域内所应遵循的最佳实践。
例如，在需求管理领域，过程目标包括了确保需求得到理解和文档化、确保需求的变更得到适当的管理和追踪、确保需求的验证等。
组织可以根据这些过程目标评估其软件开发过程的能力，并制定相应的改进计划。
CMM的体系结构使得软件开发组织能够系统地评估和改进其软件开发过程的能力。
通过逐步提高成熟度级别、改进过程领域和实现过程目标，组织可以逐渐提高软件开发的质量、效率和可靠性，从而提高业务竞争力。
虽然CMM在软件行业的影响力逐渐减弱，被一些更现代的方法和框架所取代，但其体系结构仍然具有指导意义。
例如，CMM的五个成熟度级别为其他评估模型（如CMMI）的发展提供了基础，CMM的过程领域和过程目标也为其他方法（如敏捷开发）提供了参考。
综上所述，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）在已管理级别，组织通过定量的管理和度量，对软件开发过程进行管理和优化。
cmm二级关键过程域sqa的实施大纲CMM（Capability Maturity Model）二级是针对软件开发过程质量管理的标准，其中包含了SQA（Software Quality Assurance，软件质量保证）的实施要求。
SQA是确定并确保软件开发过程满足质量标准的一系列活动，其目的是保证软件最终的可靠性和稳定性。
以下是CMM二级关键过程域SQA的实施大纲：1.计划管理。
SQA计划应当是软件开发过程中的第一步，其目的是根据CMM二级要求制定一份可靠的SQA计划。
SQA计划中应当包括SQA活动的详细描述、SQA计划执行的流程，以及SQA员工的职责和培训要求。
2.要求管理。
要求管理是SQA的重要部分之一、在这个过程中，SQA团队必须审查、审核和分析用户的软件需求，以保证这些需求的可靠性和一致性。
3.设计确认。
设计确认是SQA过程中验证开发团队是否已经将用户需求转化为可行的软件设计，确保软件设计符合标准、可行、可维护，并且符合用户需求。
4.代码审查和测试。
代码审查和测试是确保软件开发过程中代码的正确性和可靠性的重要部分。
测试应包括系统测试、集成测试和单元测试。
SQA过程中必须要定义好测试方案和测试计划，确保软件的稳定性和可靠性。
5.文档管理。
文档管理是SQA过程中的重要一环。
通过定义好的文档管理程序，可以确保开发团队在软件开发过程中能够编写完整和规范的文档。
6.配置管理。
配置管理是针对软件开发中的各个版本、程序和资源进行管理的过程，包括版本控制、变更管理、版本比较和配置管理等方面。
SQA需要定义好一种配置管理策略和程序，确保软件开发过程中的版本管理和变更管理的准确性和可靠性。
7.缺陷和分析管理。
缺陷和分析管理是SQA过程中非常重要的一环。
其目的在于通过对软件开发过程中的缺陷进行跟踪和分析，找出缺陷的源头、分析缺陷的类型和原因，以避免缺陷的再次出现。
以上就是CMM二级关键过程域SQA的实施大纲。
CMMI简介目录第一节CMMI概述 (1)1. CMMI的历史 (1)2. 软件过程成熟度 (1)3. CMMI中的成熟度等级 (2)4. CMMI的关键过程域 (3)5. CMMI的能力等级 (3)第二节CMMI的成熟度等级及其过程域 (4)1. 初始级 (4)2. CMMI已管理级 (4)3. CMMI已定义级 (6)4. CMMI量化管理级 (7)5. CMMI优化管理级 (7)第三节CMMI的应用 (8)第四节PSP，TSP与CMMI的关系 (9)1. PSP (9)2. TSP (10)第一节CMMI概述CMMI( Capability Maturity Model Integration)即能力成熟度模型集成，由CMM (Capability Maturity Model)发展而来，它最早是应用于软件业的一个过程改进模型，为软件组织描述了从混乱的、不成熟的软件过程向成熟有序的软件过程进行改进的一条途径。
后来随着应用的推广和模型本身的发展，CMMI逐渐演化成为一个被广泛应用的综合性过程改进模型。
1. CMMI的历史1991年，美国卡耐基梅隆大学软件工程研究所（SEI）推出了能力成熟度模型CMM，CMM的作用主要有两方面：为软件客户提供评价软件开发商能力的方法。
帮助软件开发商改进其软件过程，提高成熟度。
随着CMM在软件界应用的不断推广，其它相关学科和领域也采用它的模式，开发出了许多类似于CMM的模型。
SE-CMM (System Engineering CMM) 系统工程CMM，应用于系统工程管理。
SA-CMM (Software Acquisition CMM) 软件获取CMM，应用于软件获取（采购）方的能力成熟度模型。
IPD-CMM (Integrated systems product Development CMM): 集成系统产品开发CMM，应用于集成系统产品的开发管理。
P-CMM (People CMM)：人员能力成熟度模型，应用于人力资源管理。
CMMI L3标准体系详解序：2级其实有很多问题还没有解决的，细心的人会发现，2级对软件工程活动的指导很弱，如：需求开发、设计、编码、测试等。
在3级，你会发现：1)有指导需求开发的需求开发(Requirements Development)这个PA；2)有指导设计、编码工作的技术解决方案(Technical Solution)这个PA；3)有指导如何保证工作产品满足要求的验证(Verification)；4)有指导如何保证软件产品满足真实使用环境要求的(Validation)；5)还有指导如何把软件产品各组件集成在一起并保证能在相应的硬件载体运行正常的产品集成(Product Integration)；2级的PP与PMC是直接与项目管理有关的两个PA，在3级，对项目管理的要求进一步提高：6)集成项目管理(Integrated Project Management)：3级的项目管理，要求利用组织级的财富库进行项目估算，并且利用财富库裁剪出项目自己的过程，并用这个过程来管理项目。
7)风险管理(Risk Management)：2级只有PP的SP2.2中提到要识别风险，而在3级专门有一个PA对风险管理提出更高的要求。
大家不知道有没有发现，2级的PA都是直接针对项目提出要求的。
3级的IPM和RSKM，除了对项目级提出要求，另外也对组织级提出了要求，IPM要求有组织级的资产库，RSKM要求要有组织级的风险管理策略等。
另外，3级有几个“O”开头的PA，这几个PA都是直接对组织级的提出要求。
8)组织过程焦点(Organizational Process Focus)：这个PA要求组织成立SEPG来推动过程改进的工作，要求识别、计划、实施改进过程，保证组织过程能持续改进。
9)组织过程定义(Organizational Training)：这个PA要求组织级建立财富库，财富库内容要包括标准的过程、裁剪库、度量库、生命周期模型等。
一、C MM/CMMI不是软件企业唯一的选项1、一边按照CMM/CMMI做各种需要的文档，一边还在按照老传统做什么调研、方案设计、调试，跟CMM/CMMI并不合拍。
这是问题之一。
2、CMM/CMMI是一个评估的依据，也是一个过程改进的框架，并不是一个标准。
这是问题之二。
3、CMM/CMMI体现了西方的“三权分力”的思想。
SEPG相当于立法机构，而软件项目组相当于行政机构，SQA人员相当于司法机构。
三者相互制约。
这种软件项目经理和技术主管职位不分、职责不明的做法怎么能够做好CMMI? 这是问题之三。
4、CMM/CMMI不是为软件研究性项目设计的，而是为产品项目设计的。
需要搞清楚你的项目是研究性的，还是产品性的，不要盲从CMM/CMMI。
这是问题之四。
5、CMM/CMMI不可以以强权方式实施。
不能越级做CMM/CMMI。
需要收集不同项目的过程实践经验，经总结分析才能形成组织的过程。
这是问题之五。
二、实施CMM时必须解决的认识问题在企业的开发能力中过程、技术(含工具、方法)、人员都是主要的因子，都需要全面提高，只关注一个方面，而忽略了其他方面，都是有害的。
在开始实施CMM时，最容易犯的一个错误就是"唯管理论"或孤立地只抓过程改善，忽略了开发技术与人员的提高，过分强调管理的作用，实施了半年或一年后，发现企业的生产能力并没有得到明显的改善，这时反对的声音就会成为主流，过程改善就难以继续进行了。
管理就是预防，管理的作用是隐性的，不都是立竿见影的，大家要有耐心。
在实施CMM时，企业的管理层在开始时往往会对过程改善期望值太高，希望短时间内效果显著，上面我们谈到了，效果显著与否不是由一个方面的要素决定的，需要多个因素共同改善。
而管理的最大作用是预防，防患于未然。
任何的管理的改善都是符合J曲线的，即在改善的初期企业的运行效率可能会下降，甚至可能会出现一些混乱的局面，不过渡过了这段时间就会看到效果。
CMM关键过程域CMM（Capability Maturity Model）是一个软件工程目标模型，用于评估和改进组织的软件开发过程的能力。
它将软件开发过程分为五个层次，从初始（Level 1）到最优化（Level 5），每个层次都代表着一定的过程成熟度。
CMM的五个层次称为“关键过程域”，每个关键过程域都代表了一个关键的软件开发活动。
1.软件需求管理软件需求管理是指通过适当的技术和工具，对软件需求进行识别、分析、规划和管理的过程。
在这个关键过程域中，组织应明确定义需求，制定合适的需求开发计划，并确保需求管理过程与其他项目管理过程有效地整合。
2.软件项目计划与管理软件项目计划与管理是指通过合适的技术和工具，对软件开发项目的范围、任务、资源、进度和风险进行计划和管理的过程。
在这个关键过程域中，组织应制定一个合适的项目计划，明确项目的目标、范围和约束条件，并建立一个有效的项目管理过程来确保项目按时、按质量地完成。
3.软件工程与迭代开发软件工程与迭代开发是指通过适当的技术和工具，设计、开发和验证高质量的软件的过程。
在这个关键过程域中，组织应建立一个适当的软件开发方法，确保软件开发过程的可控性和迭代性，并建立一个有效的软件工程过程来确保软件的质量。
4.软件产品集成与测试软件产品集成与测试是指通过适当的技术和工具，将各个软件组件整合在一起，并进行验证和确认的过程。
在这个关键过程域中，组织应确保软件组件集成的有效性和可靠性，并建立一个有效的软件测试过程来确保软件在各个集成阶段的质量。
5.软件配置管理软件配置管理是指通过适当的技术和工具，对软件产品的配置项进行控制和管理的过程。
在这个关键过程域中，组织应建立一个适当的配置管理策略，确保软件配置项的完整性和一致性，并建立一个有效的配置管理过程来确保软件配置的可追溯性和可控性。
这些关键过程域是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 分析需求，确保符合已建立的准则。
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 确认项目工作和需求间的差异
主要活动：
●评审项目计划、活动和工作产品是否与需求和需求变更相符。
●识别差异来源及其理由。
●当需求基线有变动时，识别有关计划和工作产品所需的变更。
●启动纠正措施。
识别差距的时机？
●评审时
●变更时
●日常工作中
识别出的不一致问题要有记录，并跟踪问题的关闭需求管理我们需要客户方如何做。
●了解乙方需求变更流程，并与乙方就此流程达成一致
●指定专人负责需求变更
●内部形成一个需求变更流程
●针对内部提交的需求变更，在提交乙方之前横向分析对业务的影响
●在提交乙方之前，内部达成一致意见
●需求变更必将导致乙方开发成本增加，为保证项目成功，必要时追加合同资
金。
