软件能力成熟度模型CMM（Capability MaturityM odel）将软件能力成熟度自低到高依次划..

2014年下半年上午试卷综合知识

第 64 题


知识点	软件能力成熟度模型（CMM） CMM 能力成熟度模型需求管理
关键词	CMM 关键过程域能力成熟度模型软件能力成熟度需求管理需求
章/节	系统开发过程及其项目管理

软件能力成熟度模型 CMM（Capability MaturityM odel）将软件能力成熟度自低到高依次划分为（64）。需求管理关键过程域属于（65）。

A. 初始级、己定义级、可重复级、已管理级、优化级

B. 初始级、已定义级、已管理级、可重复级、优化级

C. 初始级、可重复级、已管理级、已定义级、优化级

D. 初始级、可重复级、已定义级、己管理级、优化级

相关试题过程评估

第64题

2009年下半年

软件能力成熟度模型(Capability Maturity Model，CMM)将软件能力成熟度自低到高依次划分为(64)。

第62题

2018年下半年

软件能力成熟度模型CMM (Capability Maturity Model)将软件能力成熟度自低到高依次划分为（62)。

第64题

2017年下半年

软件能力成熟度模型CMM(Capability Maturity Model)规定了（64)中的主要软件管理过程和工程过程的实践。

知识点讲解

· 软件能力成熟度模型（CMM）

· CMM

· 能力成熟度模型

· 需求管理

软件能力成熟度模型（CMM）

在美国国防部支持下，1987年，卡内基-梅隆大学软件工程研究所率先推出了软件工程评估项目的研究成果——软件过程能力成熟度模型（Capability Maturity Model of Software，CMM），其研究目的是提供一种评价软件承接方能力的方法，同时它可用于帮助软件组织改进其软件过程。

CMM是对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程，软件组织的能力经过这些阶段逐步前进。该能力成熟度模型使软件组织能够较容易地确定其当前过程的成熟度并识别其软件过程执行中的薄弱环节，确定对软件质量和过程改进最为关键的几个问题，从而形成对其过程的改进策略。软件组织只要关注并认真实施一组有限的关键实践活动，就能稳步地改善其全组织的软件过程，使全组织的软件过程能力持续增长。

CMM将软件过程改进分为如下5个成熟度级别，分别为：

（1）初始级（Initial）。软件过程的特点是杂乱无章，有时甚至很混乱，几乎没有明确定义的步骤，项目的成功完全依赖个人的努力和英雄式核心人物的作用。

（2）可重复级（Repeatable）。建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性。有必要的过程准则来重复以前在同类项目中的成功。

（3）已定义级（Defined）。管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。

（4）已管理级（Managed）。制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制。

（5）优化级（Optimized）。加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。

CMM模型提供了一个框架，将软件过程改进的进化步骤组织成5个成熟度等级，为过程不断改进奠定了循序渐进的基础。这5个成熟度等级定义了一个有序的尺度，用来测量一个组织的软件过程成熟度和评价其软件过程能力。成熟度等级是已得到确切定义的，也是在向成熟软件组织前进途中的平台。每一个成熟度等级为继续改进过程提供一个基础。每一等级包含一组过程目标，通过实施相应的一组关键过程域达到这一组过程目标，当目标满足时，能使软件过程的一个重要成分稳定。每达到成熟度框架的一个等级，就建立起软件过程的一个相应成分，导致组织过程能力一定程度的增长。

基于CMM模型的产品包括一些诊断工具，可应用于软件过程评价和软件能力评估小组以确定一个机构的软件过程实力、弱点和风险。最著名的是成熟度调查表。软件过程评价及软件能力评估的方法及培训也依赖于CMM模型。

CMM

CMM模型描述和分析了软件过程能力的发展程度，确立了一个软件过程成熟程度的分级标准。

（1）初始级：软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和无步骤可循的状态，软件产品所取得的成功往往依赖于极个别人的努力和机遇。初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行时没有政策、资源等方面的保证，那么它仍然被视为初始级。

（2）可重复级：已经建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成功。焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，一个可重复的过程则能逐渐演化和成熟。从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。

（3）已定义级：用于管理方面和工程方面的软件过程均已文档化、标准化，并形成整个软件组织的标准软件过程。全部项目均采用与实际情况相吻合的、适当修改后的标准软件过程来进行操作。它要求制定企业范围的工程化标准，而且无论是管理还是工程开发都需要一套文档化的标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，剪裁出项目适宜的过程，并执行这些过程。过程的剪裁不是随意的，在使用前需经过企业有关人员的批准。

（4）已管理级：软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。已管理级的管理是量化的管理。所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的产品）需有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品，量化控制将使软件开发真正变成为一个工业生产活动。

（5）优化级：通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地进行过程改进。如果一个企业达到了这一级，表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。

在CMM中，每个成熟度等级（第一级除外）规定了不同的关键过程域（Key Process Area，KPA），一个软件组织如果希望达到某一个成熟度级别，就必须完全满足关键过程域所规定的要求，即满足关键过程域的目标。每个级别对应的关键过程域见下表。

关键过程域的分类

能力成熟度模型

能力成熟度模型（简称CMM）是对一个组织机构的能力进行成熟度评估的模型。成熟度级别一般分成五级：1级-非正式执行、2级-计划跟踪、3级-充分定义、4级-量化控制、5级-持续优化。其中，级别越大，表示能力成熟度越高，各级别定义如下：

. 1级-非正式执行：具备随机、无序、被动的过程；

. 2级-计划跟踪：具备主动、非体系化的过程；

. 3级-充分定义：具备正式的、规范的过程；

. 4级-量化控制：具备可量化的过程；

. 5级-持续优化：具备可持续优化的过程。

目前，网络安全方面的成熟度模型主要有SSE-CMM、数据安全能力成熟度模型、软件安全能力成熟度模型等。

SSE-CMM

SSE-CMM（Systems Security Engineering Capability Maturity Model）是系统安全工程能力成熟度模型。SSE-CMM包括工程过程类（Engineering）、组织过程类（Organization）、项目过程类（Project）。各过程类包括的过程内容如下表所示。

SSE-CMM系统安全工程能力成熟度模型过程清单

SSE-CMM的工程过程、风险过程、保证过程的相互关系如下图所示。

SSE-CMM的工程过程、风险过程、保证过程关联图

SSE-CMM的工程过程关系如下图所示。

SSE-CMM的工程过程关联图

SSE-CMM的工程质量来自保证过程，如下图所示。

SSE-CMM的保证过程图

数据安全能力成熟度模型

根据《信息安全技术数据安全能力成熟度模型》，数据安全能力成熟度模型架构如下图所示。

数据安全能力成熟度模型架构

数据安全能力从组织建设、制度流程、技术工具及人员能力四个维度评估：

.组织建设——数据安全组织机构的架构建立、职责分配和沟通协作；

.制度流程——组织机构关键数据安全领域的制度规范和流程落地建设；

.技术工具——通过技术手段和产品工具固化安全要求或自动化实现安全工作；

.人员能力——执行数据安全工作的人员的意识及专业能力。

详细情况参考标准。

软件安全能力成熟度模型

软件安全能力成熟度模型分成五级，各级别的主要过程如下：

. CMM1级——补丁修补；

. CMM2级——渗透测试、安全代码评审；

. CMM3级——漏洞评估、代码分析、安全编码标准；

. CMM4级——软件安全风险识别、SDLC实施不同安全检查点；

. CMM5级——改进软件安全风险覆盖率、评估安全差距。

需求管理

需求管理通常包括定义需求基线、处理需求变更及需求跟踪等方面的工作。根据考试大纲和培训指南的规定，本节要求考生掌握需求变更、需求跟踪和需求变更风险管理3个方面的知识。本节只简单介绍有关需求跟踪方面的知识。有关定义需求基线和需求变更的知识，请阅读12.7.3节；有关风险管理方面的知识，请阅读12.11节。

需求跟踪的主要目的如下：

（1）审核。跟踪能力信息可以帮助审核确保所有需求被应用。

（2）在增加、删除、修改需求时可以确保不忽略每个受到影响的系统元素。

（3）使得维护时能正确、完整地实施变更，从而提高生产率。

（4）获得计划功能当前实现状态的记录。

（5）再工程。可以列出旧系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置。

（6）重新利用跟踪信息可以帮助开发人员在新系统中对相同的功能利用旧系统相关资源。

（7）可以减少由于关键成员离开项目带来的风险。

（8）可以在测试出错时指出最可能有问题的代码段。

在信息系统项目中，需求变更是不可避免的，如何以可控的方式管理软件的需求，对于项目的顺利进行有着重要的意义。如果匆匆忙忙地完成用户调研与分析，则往往意味着不稳定的需求。所以需求管理要保证需求分析各个活动都得到了充分的执行。对于需求变更的管理，则主要使用需求变更流程和需求跟踪矩阵的管理方式。

需求跟踪包括编制每个需求与系统元素之间的联系文档。这些元素包括别的需求、约束、其他设计部件、源代码模块、测试、帮助文件、文档等。需求跟踪分为正向跟踪和逆向跟踪，一般合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后续工作成果的对应关系，通过需求跟踪矩阵可以跟踪一个需求使用期限的全过程，即从需求源到实现的前后生存期。它跟踪的是已明确的需求的实现过程，不涉及需求开发人员的职责，也无法用于防止变更矩阵单元之间的可能存在“一对一”、“一对多”或“多对多”的关系。由于对应关系比较复杂，最好在表格中加必要的文字解释。当需求文档或后续工作成果发生变更时，要及时更新需求跟踪矩阵。

更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5