验证(VER)和确认(VAL)

CMMI中有关定义及英文缩写说明一、英文缩写说明●能力成熟度模型集成CMMI:Capability Maturity Model Integration ●通用目标GG：Generic Goals●特定目标SG：Specific Goals●通用实践GP：Generic Practices●特定实践SP：Specific Practices●过程域PA:Process Area●需求管理REQM:Requirement Management●项目策划PP:Project Planning●项目监督和控制PMC:Project Monitoring and ControlPlanning●供方协定管理SAM:Supplier Agreement Management●测量和分析MA:Measurement and Analysis●过程和产品质量保证PPQA:Process and Product Quality Assurance ●配置管理CM:Configuration Management●需求开发RD:Requirement Development●技术解决TS:Technical Solution●产品集成PI:Product Integration●验证VER:Verification●确认VAL:Validation●组织过程聚焦OPF:Organization Process Focus●组织过程定义OPD:Organization Process Definition●组织培训OT:Organization Training●集成项目管理IPM:Integration Project Management●风险管理RSKM:Risk Management●决策分析和决定DAR:Decision Analysis and Resolution●质量保证QA:Quality Assurance●项目经理PM：Project Manager●软件工程过程组SEPG:Software engineering process group●过程改进指导描述PIID：Process Improvement Indicator Description●SCAMPI：Appraisal Method for Process Improvement（CMMI中评估过程改进的一种方法）二、定义●共利益者（Stakeholder）：所谓“共利益者”，指的是受到某种负责产生输出的方式影响的群体或个人。

对CMMI3的学习和思考【IT168 专稿】近来笔者所在公司正在为过CMMI3做各种准备，对公司的员工进行了一些相关的培训，作为项目管理人员的我，在学习CMMI3的过程中，也有了自己的一点对于CMMI3的思考。

CMMI将软件过程中的很多步骤都通过步骤规范起来，它并没有告诉我们应该怎么去做，而只是告诉我们应该做些什么。

因为软件过程中的每一步都需要经过思考、决策、有依据才能得出过程的结果，所以减少了每一步发生错误的可能性。

一．CMMI概述CMMI是Capacity Maturity Model Integrated的简称，即集成的软件能力成熟度模型，CMM是CMMI的早期版本，它主要用于软件工程，而CMMI是一种综合性模型，它是工程实施和管理方法，它在软件与系统集成以外的如科研、工程等领域都得到了广泛的应用。

CMMI是一个由理论和经验部分组成的模型。

它有连续式和阶段式两种表述方式，其中连续式主要用于衡量一个企业的项目能力，而阶段式主要用来衡量一个企业的成熟度。

在连续式表述下，企业在接受评估时可以选择自己希望评估的项目来进行评估，所以评估通过率相对比较大，但它反映的那个相对比较窄，因为它仅仅反映该企业的该项目或类似项目达到了对应的等级。

而用阶段式来进行评估时，需由评估师自己来挑选内部的任何项目或其中的某一部分来进行评估。

阶段式的CMMI有5个等级，如下：第一级（初始级）：在该等级下，项目的目标虽然得以实现，但它的实现带有很多的偶然性和风险性，该级对人员的依赖性比较大，性能依赖个人的能力，且随个人固有的性能、知识和动机的不同而变化。

第二级（受管理级）：在该等级下，意味着组织要确保策划、文档化、执行、监督和控制项目级的过程，并且需要为过程建立明确的目标，并能实现成本、进度和质量目标等。

在这种情况下，组织已经营造了一个稳定的、受控的开发环境，项目已经在受控制的状态下运行。

该级包括如下7个过程域：需求管理（RM）、项目策划（PP）、项目监督与控制（PMC）、供方协定管理（SAM）、测量与分析（MA）、过程和产品质量保证（PPQA）和配置管理（CM）。

CMMI 22个PA缩写及主要内容CMMI 22个PA缩写EPG：工程过程组（Engineering Process Group）MSG：管理指导组/高层管理组（Management Steering Group）SPI：软件过程改进（Software Process Improvement）PAT：过程行动组（Process Action Team）PA：过程域（Process Area）PP：项目策划（Project Planning）PMC：项目监控（Project Monitoring and Control）IPM：集成的项目管理（Integrated Project Management）RSKM：风险管理（Risk Management）CM：配置管理（Configuration Management）PPQA：过程和产品质量保证（Process and Product Quality Assurance）MA：度量和分析（Measurement and Analysis）DAR：决策分析和解决方案（Decision Analysis and Resolution）REQM：需求管理（Requirements Management）RD：需求开发（Requirements Development）TS：技术解决方案（Technical Solution）PI：产品集成（Product Integration）Ver：验证（Verification）Val：确认（Validation）OPF：组织过程焦点（Organization Process Focus）OPD：组织过程定义（Organization Process Definition）OT：组织培训（Organizational Training）22个PA的主要内容有：1．CM：（Configuration Management）软件配置管理。

验证（Verification）与确认（Validation）的区别今天在⼀位朋友的提醒下，发现ITIL V3术语表⾥有⼀处错误：Verification和Validation都翻译成了“验证”，这是⼀个很⼤疏忽和错误。

其实这两个词是⾮常近似的，到底怎么翻译好呢？Validation是否应该翻译为"检验"⽽不是“验证”？在征求了很多⼈，尤其是⼀些做过测试的朋友的意见，CMMI中也是专门有验证(Verification)与确认(Validation)两个PA来描述这两⽅⾯的要求的。

验证(Verification)，是通过提供客观证据证明规定的要求是否得到满⾜,也就是说,输⼊与输出⽐较。

确认(Validation)，是在验证好的基础上,对预期的使⽤和应⽤要求是否得到满⾜,也就是说,在确认时,应考虑使⽤和应⽤的条件范围要远远⼤于输⼊时确定的范围.⼀般是由客户或代表客户的⼈执⾏。

找了个有意思的解释，以下为转贴：Verification and ValidationVerification也就是说要做正确、⽽Validation是看经过Verification是否是我们想要的。

Verificaiton是我们可以预见的，在测试以前就知道我们期望⼀个什么结果。

例如我要找GF，⾸先对⽅要是个⼥的，if（Person.gender!=female) return false；做IC的，读卡器芯⽚，必须能够读相应的数码卡；做sales的，评价Performance的标准每个⽉的销售额就是Verification的标准，Verification是否可以说是理性思维⼤于感性。

1是1，2是2。

⽽Validation⾸先前提是经过Verification，重要的是做的是否是customer需要的。

拿刚才三个例⼦，我相信任何⼀个⼈找对象，不会只需要⼀个异性。

验证Validation，还要看是否是⾃⼰喜欢的; IC做出来了，是否市场真的需要。

1. CMM分哪几个成熟度等级？每个等级的名称是什么？有什么含义？2. CMMI是在什么历史条件下产生的？与CMM之间的关系是怎样的？3. CMMI有哪两种表现形式？CMMI与CMM相比，在过程域方面有什么变化？4. 什么是软件过程的改进？CMM/CMMI对于指导软件过程改进有什么意义？5. RUP的静态结构和动态结构是怎样的？静态结构由哪五种元素组成？各自代表什么？动态结构中的周期、阶段、迭代、里程碑等等之间是一种怎样的关系？6. RUP提倡的6大最佳实践是什么？怎样认识这些最佳实践？7. 什么是制品？RUP中有哪些制品集？各种典型的制品属于哪一类制品集？ 8. 什么是软件配置管理？它能解决软件开发中的哪些问题？9. 什么是开发团队中的SQA、SEPG、项目经理、软件架构师？他们的职责是什么？10 CMM有哪18个软件过程域？它们的主要活动各是什么？11. 什么是软件需求管理？在RUP中，需求规程的输出结果是什么？12. 什么是软件复杂度？怎样降低软件复杂度？13. 什么是软件危机？它的表现是什么？解决软件危机的途径是什么？14. 怎样进行软件过程评估？主要的评估手段有哪些？15. 软件开发中有哪几种典型的测试？它们各自解决什么问题？16. 什么是软件过程的可视性？怎样提高软件过程的可视性？17. 什么是软件系统架构？怎样表示架构？什么是模型？它们之间是什么关系？18. 什么是基线？有什么特点？起什么作用？19. 什么是软件过程的财富库？它有哪些组成部分？由哪一个关键过程域维护它？20.什么是用例？用例模型起什么作用？21. 软件过程的不确定性表现在哪些方面？有哪些解决办法？22. 什么是迭代开发？与顺序开发相比，它有什么优点？23. 什么是软件缺陷？怎样对缺陷进行管理？24. RUP提倡的开发周期中有哪些阶段？每个阶段的名称是什么？各自解决什么问题？评价准则是什么？2. 能力成熟度模型的基本出发点是什么？能力成熟度模型由哪些部分组成？答：能力成熟度模型是一种用于评价软件承包商能力并帮助改善软件质量的方法，其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。

CMMI 22个PA缩写及主要内容关键字：CMMI,CMMI PACMMI 22个PA缩写EPG：工程过程组（Engineering Process Group）MSG：管理指导组/高层管理组（Management Steering Group）SPI：软件过程改进（Software Process Improvement）PAT：过程行动组（Process Action Team）PA：过程域（Process Area）PP：项目策划（Project Planning）PMC：项目监控（Project Monitoring and Control）IPM：集成的项目管理（Integrated Project Management）RSKM：风险管理（Risk Management）CM：配置管理（Configuration Management）PPQA：过程和产品质量保证（Process and Product Quality Assurance）MA：度量和分析（Measurement and Analysis）DAR：决策分析和解决方案（Decision Analysis and Resolution）REQM：需求管理（Requirements Management）RD：需求开发（Requirements Development）TS：技术解决方案（Technical Solution）PI：产品集成（Product Integration）Ver：验证（Verification）Val：确认（Validation）OPF：组织过程焦点（Organization Process Focus）OPD：组织过程定义（Organization Process Definition）OT：组织培训（Organizational Training）主要内容有：1．CM：（Configuration Management）软件配置管理。

CMMI3级过程域CMMI3级是CMMI（Capability Maturity Model Integration，能力成熟度模型集成）的一个等级，它代表了一个组织在其软件开发和管理过程方面的成熟度水平。

CMMI3级要求组织在战略规划、项目管理和工程实践等方面都进行了规划和实施，并能够通过度量和分析来改进其过程。

本文将针对CMMI3级中的过程域（PA）进行详细介绍。

1. Requirements Development (RD) —需求开发需求开发是指定义和收集项目所需的功能和约束条件，并确保其正确性、准确性和一致性的过程。

这个过程域包括需求的获取、分析、规范和验证等活动。

在CMMI3级中，组织需要建立适当的需求开发过程，确保需求的完整性和明确性，同时也要进行需求的管理和变更控制。

2. Technical Solution (TS) —技术解决方案技术解决方案是指开发和维护软件的过程，包括软件架构设计、详细设计、编码和单元测试等活动。

在CMMI3级中，组织需要确保对技术解决方案进行详细规划和实施，包括选择合适的架构和技术，检查和审查设计和代码等。

同时，组织也需要建立和执行软件配置管理和版本控制等活动。

3. Product Integration (PI) —产品集成产品集成是指将不同的软件构件组合起来，并进行验证和部署的过程。

在CMMI3级中，组织需要建立适当的产品集成过程，确保集成的正确性和稳定性，同时也要进行集成测试和验证。

组织还需要建立相应的配置管理和版本控制机制，确保产品集成的可控性和可追溯性。

4. Verification (VER) —验证验证是指在软件开发过程中对产品的需求进行确认和验证的过程。

在CMMI3级中，组织需要建立适当的验证过程，包括验证计划的制定、验证活动的执行和验证结果的分析。

验证活动可以包括软件测试、代码审查、功能验证等，以确保开发的产品符合需求和规范。

5. Validation (VAL) —验证确认验证确认是指在软件开发过程结束后对最终产品进行确认和验证的过程。

验证(Verification)与确认（Validation）的差别说法一：（2）“验证(Verification)”的涵义通过提供客观证据对规定要求已得到满足的认定。

（2）“确认（Validation）”的涵义通过提供客观证据对特定的预期用途或应用要求已得到满足的认定。

（3）“验证”和“确认”之差别“验证”和“确认”都是认定。

可是，“验证”表明的是满足规定要求，而“确认”表明的是满足预期用途或应用要求，说简单点，“确认”就是检查终于产品是否达到顾客使用要求。

（4）“设计和开发”中“设计验证”和“设计确认”之差别在于：设计验证的目的是检查设计输出是否满足设计输入的规定要求。

设计确认的目的是检查设计形成的终于产品是否达到顾客的使用要求。

说法二：1.“确认”是要证明所提供的（或将要提供的）产品适合其估计的用途，而“验证”则是要查明工作产品是否恰当地反映了规定的要求。

换句话说，验证要保证“做得正确”，而确认则要保证“做的东西正确”。

2.验证注重“过程”，确认注重“结果”3.(Verification) －－－Are we producing the product right?(Validation) －－－Are we producing the right product?说法三：1.什么是验证？验证就是要用数据证明我们是不是在正确的制造产品。

注意这里强调的是过程的正确性2.什么是确认？确认就是要用数据证明我们是不是制造了正确的产品。

注意这里强调的是结果的正确性。

3.验证和确认是一个广泛的概念，感兴趣的读者能够參考IEEE Std 1012-1998 。

验证：验证检查某样东西是否符合之前已定好的标准，如：文档评审，要检查的东西是文档，检查标准就是文档的评审标准，又如：測试软件，要检查的东西就是软件，检查的标准就是软件的规格说明，包含功能说明，性能要求等。

确认：检查软件在终于的执行环境上是否达到预期的目标。

文件修订履历
目录
目录 (4)
1.目的 (1)
2.适用范围 (1)
3.方针要求 (1)
4.职责 (1)
验证和确认方针*** 软件有限公司1/1 1. 目的
验证和确认的目的是保证工作产品满足其规定的要求和用户的需求。

2. 适用范围
覆盖全部软件开发项目。

3. 方针要求
1.为验证和确认选择合适的工作产品
2.建立验证和确认环境
3.建立验证和确认程序和标准
4.制定验证和确认计划，包括资源和程序
5.由项目经理制定同行评审计划
6.实施同行评审，记录同行评审，发布同行评审报告，确定修改措施，修改工作产品，通过
复核及客户评审
7.由测试组长制定测试计划。

8.项目经理审批测试计划和监控测试活动进度。

9.实施测试，发布测试缺陷报告，确定修改措施，修改工作产品，提交测试报告，通过审查4. 职责。

CMMI3简介CMMI三级，称为定义级。

在定义级水平上，企业不仅能够对项目的实施有一整套的管理措施，并保障项目的完成；而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套管理体系与流程予以制度化，这样企业不仅能够在同类的项目上生到成功的实施，在不同类的项目上一样能够得到成功的实施。

科学的管理成为企业的一种文化，企业的组织财富。

在CMMI3级，你会发现：PA过程域1)有指导需求开发的需求开发(Requirements Development)这个PA；2)有指导设计、编码工作的技术解决方案(Technical Solution)这个PA；3)有指导如何保证工作产品满足要求的验证(Verification)；4)有指导如何保证软件产品满足真实使用环境要求的(Validation)；5)有指导如何把软件产品各组件集成在一起并保证能在相应的硬件载体运行正常的产品集成(Product Integration)；CMMI2级的PP与PMC是直接与项目管理有关的两个PA，在CMMI3级，对项目管理的要求进一步提高：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来推动过程改进的工作，要求识别、计划、实施改进过程，保证组织过程能持续改进。

验证VER验证（VER）：生产活动的输出正确地满足其输入（built it right）。

VER目的是：确保选择的工作产品符合它们的给定需求。

1、SG1：执行验证前准备。

（1）SP1.1：选择被验证的工作产品及相应的验证方法。

验证什么？如何验证？测试、同行评审、审查、走查、模拟、演示……（2）SP1.2：建立并维护验证所需的支撑环境。

一般地，不同的验证方法需要不同的支持条件；被验证的工作产品不同，需要的支持条件也可能不同。

（3）为选定工作产品建立并维护验证的步骤和准则。

验证的步骤是什么？通过验证的标准是什么？2、SG2：对选定的工作产品实施同行评审。

（1）SP2.1：为选定工作产品的同行评审进行准备。

参加评审的人员及其角色；使用的checklist；评审活动时间表；准则——是否符合评审条件、是否需要再次评审；……（2）SP2.2：对选定的工作产品执行同行评审，并识别通行评审过程产生的问题。

执行同行评审、发现问题；收集同行评审过程和结果的统计数据。

（3）SP2.3：分析同行评审数据，包括准备过程、实施过程和结果。

记录、保存、分析、使用评审过程统计数据；“适当的使用”——评审结果不被用于绩效评价。

3、SG3：根据给定的需求验证选定的工作产品。

（1）SP3.1：对选定的工作产品实施验证。

尽早发现、排除缺陷。

（2）SP3.2：分析所有验证活动的结果，识别纠正活动。

根据已定义的标准确定是否通过了验证；解决验证发现的问题。

确认V AL确认（V AL）：产品满足预期使用需求（built the right thing，确认未必一定是通过最终产品进行）。

目的是：展示产品或产品组件能够在其预期的环境中满足其预期的应用。

1、SG1：执行确认前准备。

（1）SP1.1：选择被验证的产品或产品组件及其相应的验证方法。

识别客户对确认的约束是重要的——对于产品的验证需求；对产品的确认可通过工作产品进行。

（2）SP1.2：建立并维护确认所需要的支撑环境。

CMMI3工程组人员访谈常见问题,需求带答案工程组(Engg)访谈问题汇总：一、需求开发与管理（RD、REQM）1、如何导出客户的需求？制定需求调研计划，准备需求提问单，调查表，通过会议、访谈、电话等方式对系统使用人员，熟悉系统业务规则的人，决策者等相关人员进行需求调研，调研的题纲为功能需求、场景、非功能需求、界面。

环境、性能、接口、产品验收、交付。

2、如何进行需求开发？需求开发的主要活动有哪些？导出用户需求，开发用户需求说明书，评审CRS，客户确认用户需求说明书，开发产品需求说明书，评审，客户确认。

需求管理的活动主要是：控制变更，维护需求跟踪矩阵，需求不一致记录3、用户需求说明书包含哪些主要内容？功能需求、场景、非功能需求、界面。

环境、性能、接口、产品验收、交付方式时间4、如何进行需求评审？需求评审有哪些准则？进行正式的会议评审，非正式的有EMAIL会签，走查。

准则有：可追溯性，正确性，完整性，一性性，可行性，无二义性，可验证性，必要性，可理解性，划分优先级，具有楖要设计所需的相关输入信息。

5、用户需求如何得到验证？评审确认6、需求的约束条件在哪里记录？产品需求规格说明书的项目概述－》有一节是假定和约束：列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等7、产品需求说明包括哪些内容？产品需求与用户需求的区别在哪里？产品介绍描述用户群体的特征定义产品的范围阐述产品应当遵循的标准和规范定义产品中的角色定义产品的功能性需求定义产品的非功能性需求，如用户需求、软硬件环境、质量等需求规格说明书包括：用例、系统总体结构图、用户需求的细化（功能性和非功能性需求），接口的需求、界面需求差别：先将客户需求变为产品需求，再将各功能点非配到相应功能模块，然后识别接口需求，将内部接口和外部接口分开8、如何描述需求模块模块功能编号，名称，模块优先级，然后对其功能进行描述，数据描述，设定相应约束条件，使用岗位，关联模块9、RTM的主要内容有哪些？RTM有没有定期评审？分配的需求ID，软件需求规格ID，系统测试用例标识，ST用例执行情况，概要设计，集成测试用例标识，详细设计，单元测试用例标识，代码。

CMMI基础知识一、CMMI简介CMMI（Capability Maturity Model Integration,能力成熟度模型集成)是用于产品开发(或服务）的过程改进成熟度模型。

CMMI的最佳实践覆盖了产品构思、交付和维护的整个生命周期。

CMMI源自于CMM。

1984年美国国防部为了降低采购风险,委托卡耐基—梅隆大学软件工程研究院（SEI)制定了软件过程改进、评估模型，也称为SEI SW—CMM。

该模型于1991年正式推出，迅速得到广大软件企业及其顾客的认可.经过不断研究，相继推出了其他领域的CMM模型，比如:（1) SE-CMM (System Engineering CMM）: 系统工程CMM(2）SA-CMM （Software Acquisition CMM）：软件采购CMM（3）IPT-CMM （Integrated Product Team CMM）: 集成产品群组CMM（4) P-CMM (People CMM）：人力资源能力成熟度模型之后将各种CMM模型进行整合，形成了CMMI.2002年CMMI1.1版本正式发布，并立即被广泛采用，2006年8月，面向开发的CMMI（CMMI—DEV 1。

2）版本正式发布.目前正在使用的就是这个版本。

下面讲的CMMI是指CMMI—DEV1。

2,针对软件方面的.通过上面的介绍，可以清楚地知道CMMI这几个字母的含义,CM:能力成熟度.不同的成熟度对应不同的等级,一共有五个等级；M :模型. CMMI提供一个标准的模型,企业的软件能力成熟度是否达到对应的级别，要和这个模型进行比较。

I ：集成。

将各个不同领域的CMM进行抽象整合.也就是说CMMI不仅适合于软件领域，同样适合于其他领域。

二、CMMI的五个等级CMMI的阶段式表示法将成熟度划分为5个等级.除了初始级以外，每个成熟度等级都有若干个过程域，如下表所示。

由于成熟度等级是循序渐进的，如果想达到某个成熟度等级，例如CMMI 3级，除了满足CMMI 3级本身11过程域之外，还要满足CMMI 2级的7个过程域，依此类推。

CMMI中有关定义及英文缩写说明一、英文缩写说明l 能力成熟度模型集成CMMI:Capability Maturity Model Integrationl 通用目标GG：Generic Goalsl 特定目标SG：Specific Goalsl 通用实践GP：Generic Practicesl 特定实践SP：Specific Practicesl 过程域PArocess Areal 需求管理REQM: Requirement Managementl 项目策划PProject Planningl 项目监督和控制PMCroject Monitoring and Control Planningl 供方协定管理SAM:Supplier Agreement Managementl 测量和分析MA:Measurement and Analysisl 过程和产品质量保证PPQA:Process and Product Quality Assurancel 配置管理CM:Configuration Managementl 需求开发RD:Requirement Developmentl 技术解决TS:Technical Solutionl 产品集成PI:Product Integrationl 验证VER:Verificationl 确认VAL:Validationl 组织过程聚焦OPF:Organization Process Focusl 组织过程定义OPD:Organization Process Definitionl 组织培训OT:Organization Trainingl 集成项目管理IPM:Integration Project Managementl 风险管理RSKM:Risk Managementl 决策分析和决定DARecision Analysis and Resolutionl 质量保证QA:Quality Assurancel 项目经理PM：Project Managerl 软件工程过程组SEPG:Software engineering process groupl 过程改进指导描述PIID：Process Improvement Indicator Descriptionl SCAMPI：Appraisal Method for Process Improvement （CMMI中评估过程改进的一种方法）二、定义l 共利益者（Stakeholder）：所谓“共利益者”，指的是受到某种负责产生输出的方式影响的群体或个人。