CMM中的需求管理与需求开发

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的实施大纲。