4.1 解释关键实践
我们制定关键实践的意图不是要求或者主张某个具体的软件生存周期模型，某种具体的
组织机构、某种具体的职责划分或某种具体的用于开发的管理和技术方法，而是给出对有效
软件过程的基本元素的描述。
打算用关键实践来传达那些基本原理，它们能适用于种类广泛的项目和组织，对许多典
型的软件应用都正确，且随时间的推移仍然有效。所以我们的办法是描述原理，而将其具体
实施留给每个组织，按其文化和职员及经理的经验去做。
虽然关键实践不依靠任何具体的实施，但在叙述关键实践时必须一致地使用特定的术语
和例子以提高文字的清晰度。本节描述CMM 中对角色、职责、关系、产品和活动所用的约
定术语。使用关键实践的组织应该了解这些约定术语，并在自己的组织、项目和经营环境中
恰当地说明它们。
附件B 中的术语汇编收纳了术语的定义，包括在本节和其它地方已描述过的术语。

4.2.1 解释共同特点
在关键实践的每个共同特点中，为了在关键过程区域之间提供连续性和一致性，采用某
些短语和约定术语。下面描述组织机构方面的主要的约定术语，按共同特点排列。

4.3 解释软件过程定义
为达到较高的成熟度等级，软件过程定义是非常根本的。本节仅讨论软件过程定义的一
些方面，这些方面对于使用与过程定义有关的关键实践是有帮助的，从等级3 的组织过程定
义开始讨论。
CMM 中过程定义的一个基本概念是组织标准软件过程。组织的基本过程指导建立一个
近历组织中所有软件项目的共用的软件过程，而组织标准软件过程就是此基本过程的可操作
的定义。组织标准软件过程描述基本的软件过程元素，它们是预计每个软件项目都会引入到
自己的项目定义软件过程中去的过程元素。它也描述这些软件过程元素间的关系（例如排序
和界面）。它在全组织中建立起开展软件活动的一致方式，这对长期的稳定性和长期改进是
十分重要的。
在组织层上，组织标准软件过程需要以正式的方式加以描述、管理、控制和改进。在项
目层上，强调的是项目定义软件过程的适用性，和它给项目带来的益处。一个项目定义软件
过程是该项目所用软件过程的可操作定义。项目定义软件过程是很好地特征化了的和已理解
的软件过程，用软件标准、规程、工具和方法加以描述。通过剪裁组织标准软件过程使其适
合项目的具体特征来制定项目定义软件过程。
有一种过程定义的方法既能支持定义的稳定性又能支持定义的灵活性，在组织过程定义
的关键实践的描述中就采用能反映这种方法的术语。图4.1 中描述了这种方法，在随后几节
中描述它的关键元素。

4.3.1 过程定义的概念
支持SEI 在其过程定义工作中所采用方法的基本概念是能够以类似于开发和维护产品
的方式来制定和维护过程。因此它必须有：
?? 需求，它定义待描述的是什么过程；
?? 体系结构和设计，它提供将如何定义过程的信息；
?? 在项目或组织的情况下，过程设计的实现；
?? 藉助于测量，对该过程描述的确认；和
?? 在原定使用该过程的组织或项目内，该过程的推广运用。
采用类比于产品开发的方法，用于软件过程开发和维护的框架已经逐渐形成，它将这些
概念转化成更为专门用于过程开发学科的概念（类似于将开发管理信息系统下所用术语转化
为开发实时嵌入式系统所用术语的专门性）。图4．1 显示该框架的关键元素，并在下面加以
简要描述。

关于过程工程界内正在开发的过程定义的概念，进一步阅读可参考文章“Software
Process Development and Enactment：Concepts and Definifions”"软件过程开发和规定：概念
和定义")[Feiler 92]。

4.4.2 组织机构
必须充分理解有关组织、项目和组的基本概念，以便恰当地解释能力成熟度模型的关键
实践。以下段落定义这些概念在CMM 中的用法：

4.2.1 解释共同特点
在关键实践的每个共同特点中，为了在关键过程区域之间提供连续性和一致性，采用某
些短语和约定术语。下面描述组织机构方面的主要的约定术语，按共同特点排列。
4.2.1 执行约定
方针陈述
（Policy statement）
当采用方针陈述时，它们一般指的是项目遵循书面的、用于那个
关键过程区域的实践的组织上的方针。这是为了强调在组织上的约定
和实际正进行工作的项目之间的连结。
方针陈述的子实践通常概述以后将被包括在关键过程区域中并
特别适合于通过书面方针加以规范化的活动。
在某些关键过程区域（例如组织过程焦点）中，关键过程区域的
活动的焦点是组织，而不是项目。这种情况下方针陈述要改写，并且
指的是组织遵循书面方针。
领导
（leadership）
在某些关键过程区域，执行约定包含一个阐述任命一个领导角色
（例如项目软件经理）的语句，或者一个描述特别资助活动的语句，
这些是成功地规范化该关键过程区域所必须的。
4.2.2 执行能力
资源和投资大多数关键过程区域包含一个反映关键过程区域的活动对适当
（Resources and
funding）
的资源和投资要求的关键实践。由子实践描述的资源及投资一般分成
三类；能利用的特别的技能、足够的投资和能利用的工具。作为例子，
列出在执行关键过程区域活动中可能利用的工具。
采用“投资（funding）”这个词而不用“预算（budget）”这个词
是为了强调，对于实际过程而言，已交付的和已使用的东西要比许诺
的东西更有实际价值。
培训
（training）
对于术语培训，CMM 中所指的范围比通常使用此术语时所考虑
的要宽。提供培训是为了使得个人精通专门的细则和实践。该培训可
以包括正式的和非正式的在组织中将技能和知识传授给个人的办法。
虽然课堂培训是许多组织所采用的培育雇员技能的办法，但CMM还
提供其它的手段，例如方便的录相教学、计算机辅助指导、或者正规
的师徒计划。培训大钢这个关键过程区域描述与这些培训办法有关的
具体实践。在CMM 的所有地方一般能发现描述培训的两个样板短
语。在等级2 使用短语“接受培训”，在等级3 以上使用短语‘’接
受所要求的培训”。使用这些不同样板短语的意图是，区别出等级2
上的培训多半尚未在全组织范围内规范化。在等级3 和更高等级，预
料培训大纲这个关键过程区域的关键实践能控制组织的培训活动。在
所有的关键过程区域，潜在可能的培训专题用例子块表示，承认不同
的组织情况多半有不同的具体培训需要。
走向培训
（orientation）
在某些关键过程区域，能找到描述定向培训的关键实践。广泛使用术
语定向培训去指明所传授的技能和知识的深度要比由培训传授的浅。
定向培训是对一个专题所作的概述或介绍，其对象是那些对在该专题
范围内负责进行工作的个人加以监督和打交道的人。
先决条款
（Prerequisite Items）
某些关键过程区域包括描述要求先决条款的关键实践；例如，软
件开发计划是软件项目跟踪和监督的先决条款。在某些情况下，这些
先决条款可能为另一个关键过程区域活动的输出。在另一些情况下，
它们是预期能从软件项目范围之外获得的条款（例如，分配给软件的
系统需求是需求管理的先决条款）。
与CMM突出“关键”实践的哲理相一致，对每个关键过程区域
并不列出全部先决条款。在CMM中仅仅引用那些已被发现对关键过
程区域的实施起特别关键作用的先决条款。
4.2.3 执行的活动
在产所有的共同特点中，执行的活动显示出最多的结构可变性，因为关键过程区域的实


施活动在细节层次上、组织方面的焦点（例如，项目或组织）上，和对策划及文档化的要求
上各不相同。下面突出阐述某些一般的概念。
计划的类型
（Types Of plans）
在关键实践中所描述的两个主要的计划类型是：正式计划（例如：
软件开发计划、软件质量保证计划和软件配置管理计划）及非正式计
划（例如同行评审计划、风险管理计划和技术管理计划）。
非正式计划一般编写为正式计划的一部分（例如，同行评审计划
可以作为软件开发计划的一部分）或者作为正式计划的附件（例如，
同行评审进度表可以是软件开发计划中的一节）。正式计划要求有管理
者的高度支持，无论从制定这些计划的立场上看还是从保证它们得到
遵循的立场上看均是如此。在签约环境中这些计划一股交付给作为合
同甲方的顾客。
正式计划
（Formal Plans）
在提到正式计划时，通常有两个关键实践专门描述策划活动：一
个关键实践要求按照已文档化的规程制定和修改计划，另一个要求关
键过程区域的活动基于计划。涉及已文档化的规程的子实践的内容包
括；计划的输入所必须有的内容和为了获得计划所要求的约定和支持
预计需采取的步骤。这些干实践标识出该计划的典型评审者，还突出
说明预期的批准等级。
有些计划是活动的基础，与这些计划有关的干实践描述这些计划
所预计有的内容。在描述计划内容方面可以提供不同层次的细节，它
取决于计划的类型和在包括哪些一般的计划专题方面有关组织灵活性
的要求。
非正式计划
（litormal plans）
通常非正式计划由单个关键实践描述。其子实践包括有关计划内
容的信息和用于制定或修定计划的规程。
按照文档化的现程
（ According to a
documented
procedure）
一般需要一个文档化的规程，这样，负责～个作业或活动的个人
能以重复的方式执行它，而且其它具有该领域一般知识的人员也能学
会并以同样的方式执行该作业和活动。这是使过程规范化的一个方面。
文档化规程的形式和细节层次可能变化很大，从手写的个人的桌面规
程到正式的组织的标准操作规程。形式和细节层次依赖于谁将执行该
作业或活动（例如，个人或群组），执行频率，结果的重要性和所预计
的用途，以及结果的预计接收者。
分配给软件的系统
需求(System
requirements
allocated to
Software)
在CMM 中分配给软件的系统需求通常称为“分配需求”，它是系
统需求中将用系统的软件成分实现的子集。分配需求是软件开发计划
的主要输入。软件需求分析详细阐述和精炼分配需求，结果产生文档
化的软件需求。
顾客需求涉及整个的系统，不只是软件。CMM中，对顾客需求的
讨论集中于那些将用软件实现的顾客需求。将系统需求分配给硬件、
软件等等是整个系统设计的一部分，一般由系统工程组完成。分配给
软件项目的系统需求在CMM 中一般称作“分配需求”，既包括技术需
求（功能性、性能等等），也包括非技术需求（交付日期、成本等等）。
顾客一供应商关系
(Customer supplier
relationship)
顾客可以是组织内部的，也可以是组织外部的。内部顾客的一个例子
是营销小组；外部顾客的～个例子是国防部。用户也可能不同于顾客，
国防部签约环境中情况正是如此。CMM 是用外部顾客加以表述的，他
们是采购带有关键软件成分的系的人员或组织在需要处必须恰当地解
释（正如在CMM 中所述的）组间的边界，例如，在仅仅采购软件的情
况下，顾客和软件工程组之间可以没有系统工程组。此时，顾客需求、
系统需求和分配需求可能是同义语，系统工程组的职责将由顾客及软


件工程组分担。
按管理要求进行跟
踪和采取纠正措施
(Tracking and
等级2 在软件项目跟踪和监督关键过程区域中的许多关键实践采用短
语“跟踪⋯，必要时采取纠正措施。”在等级3 的集成软件管理中的许
多类似的关键实践采用短语“进行管理”。这个用字上的差异反映出等
Taking
correctiveaction
versus managing)
级2 上的项目缺乏一个完全定义的软件过程。管理措施很可能是对实
际问题的反应。在等级3 上项目有一个完全定义的软件过程，不同软
件工作产品、作业和活动之间的关系也是妥善定义的。管理者更能预
见会出现的问题并能预先采取措施防止它们发生。在要求进行干预时，
干预对整个软件过程的效果是清楚的，因而能更有效地定义和运用这
些干预。
经过评审和经过同
行评审的比较
(Reviewed versus
under goes peer
reviews)
在评审中，将一个软件工作产品或一组工作产品提交给经理、顾客、
最终用户、或其它有兴趣的个人，以得到他们的评论或批准。评审一
般出现在作业结束时。在同行评审中，将一个软件工作产品或一组工
作产品提交给生产者的同事们以识别出缺陷。经理、顾客或终端用户
一般不出席同行评审。同行评审是作业过程中不可缺少的部分。进行
同行评审使得缺陷能及早排除，导致较高的生产率和高质量的产品。
某些软件工作产品将经过评审；某些将经过同行评审；还有一些将既
经受评审又经受同行评审。
置于配置管理之下
与之进行管理和控
制相比较
(Placed under
configuration
management versus
managed and
Controlled)
某些软件工作产品，例如软件设计和代码，应在预先确定的点上
建立基线。这些基线经过正式评审和认同，作为进一步开发工作的基
础。对已基线化的配置项施加严格的更改控制过程。在与顾客打交道
时，这些基线提供控制和稳定性。有时称此为基线配置管理。短语“置
于配置管理之下”用于此类软件工作产品。当配置控制由开发者实施
时，通常称之为开发配置管理。在预先确定的开发中的某些点上，开
发配置管理下的某些项可置于基线配置管理之下。虽然对短语“置于
配置管理之下”的解释可扩展至开发配置管理，但是正确的基本解释
是仅要求实施基线配制管理。
某些软件工作产品，例如估计或软件开发计划，可以不必置于配
置管理之下，但仍然需要“进行管理和控制”。这些软件工作产品不是
基线的一部分，因此不用置于配置管理之下，但它们必须受控以使得
项目按一种有纪律的方式进行工作，短语“进行管理和控制”用于对
标识和定义这种软件工作产品的过程进行特征描述。“进行管理和控
制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知
的（即版本控制），并且更改以一种受控的方式引入（即更改控制）。
4.2.4 测量和分析
测量和分析这个共同特点中的关键实践描述基本的测量实践，对确定与关键实践的执行
的活动这一共同特点有关的状态来说，这些测量实践是必不可少的。有些测量是关键过程区
域中活动的固有部分，这些测量则被列在执行的活动这一共同特点之下。
所建议的测量例子都表示为补充信息，因为项目环境的可变性可以导致不同的测量需要
和方法。
4.2.5 验证实施
验证实施这个共同特点一般包含与高级管理者和项目管理者的监督有关的关键实践，以
及某些专门的验证活动，后者预期由质量保证组成其它组执行，以证实关键实践正在恰当地
进行。
高级管理者的定期监
督
Senior management
oversight on a periodic


basis
高级管理者作定期评审的主要目的是在合适的抽象层次上和
以及时的方式了解和洞察软件过程活动。评审间隔应满足组织的需
要，只要已存在有报告例外情况的合适机制，间隔可以长。
高级管理者评审的范围和内容很大程度上依赖于评审中所涉
及的是哪些高级经理。在评审的时间表和所阐述的问题方面，预期
负责组织的全部软件活动的高级经理作的评审与整个组织的高级
行政负责人作的评审不同。预期高级管理者的评审还会包含与项目
管理者监督评审不同的专题，或者包含类似的专题但在一个更高的
抽象层次上。
项目管理者既定期地
也事件驱动地监督
（ Project management
oversight on both a
periodic and erent
driver basis ）
为了强调项目在不同的阶段和依赖于项目的不同特征而需要
不同类型的评审，在这些关键实践的描述中采用样板短语“既定期
地也事件驱动地”。项目管理者应保持对软件工作状态的不断了解，
并在软件项目出现重大事件时收到报告。例子包括项目管理者参加
诸如关键设计评审那样的正式评审，和围绕过程问题的评审——例
如．有关过程改进规划的状态和过程不符合问题的解决等的评审。
预计在项目层上，项目管理者的监督要比高级管理者的监督详细，
反映出项目管理者更为积极地卷入项目的运行方面。
软件质量保证活动
（ Software quality
assurance activities）
用一个关键实践描述那些据信适宜于软件质量保证（SQA）组
作评审和（或）审计的特定活动。但存在一些特殊情况，在那里
SQA 验证活动未被描述，例如在培训大纲和组间协调关键过程区域
中。这些是处在软件项目和组织间的边界上的关键过程区域，预计
在这里SQA 组不会有权威。
4.3 解释软件过程定义
为达到较高的成熟度等级，软件过程定义是非常根本的。本节仅讨论软件过程定义的一
些方面，这些方面对于使用与过程定义有关的关键实践是有帮助的，从等级3 的组织过程定
义开始讨论。
CMM 中过程定义的一个基本概念是组织标准软件过程。组织的基本过程指导建立一个
近历组织中所有软件项目的共用的软件过程，而组织标准软件过程就是此基本过程的可操作
的定义。组织标准软件过程描述基本的软件过程元素，它们是预计每个软件项目都会引入到
自己的项目定义软件过程中去的过程元素。它也描述这些软件过程元素间的关系（例如排序
和界面）。它在全组织中建立起开展软件活动的一致方式，这对长期的稳定性和长期改进是
十分重要的。
在组织层上，组织标准软件过程需要以正式的方式加以描述、管理、控制和改进。在项
目层上，强调的是项目定义软件过程的适用性，和它给项目带来的益处。一个项目定义软件
过程是该项目所用软件过程的可操作定义。项目定义软件过程是很好地特征化了的和已理解
的软件过程，用软件标准、规程、工具和方法加以描述。通过剪裁组织标准软件过程使其适
合项目的具体特征来制定项目定义软件过程。
有一种过程定义的方法既能支持定义的稳定性又能支持定义的灵活性，在组织过程定义
的关键实践的描述中就采用能反映这种方法的术语。图4.1 中描述了这种方法，在随后几节
中描述它的关键元素。
4.3.1 过程定义的概念
支持SEI 在其过程定义工作中所采用方法的基本概念是能够以类似于开发和维护产品
的方式来制定和维护过程。因此它必须有：
?? 需求，它定义待描述的是什么过程；
?? 体系结构和设计，它提供将如何定义过程的信息；
?? 在项目或组织的情况下，过程设计的实现；


?? 藉助于测量，对该过程描述的确认；和
?? 在原定使用该过程的组织或项目内，该过程的推广运用。
采用类比于产品开发的方法，用于软件过程开发和维护的框架已经逐渐形成，它将这些
概念转化成更为专门用于过程开发学科的概念（类似于将开发管理信息系统下所用术语转化
为开发实时嵌入式系统所用术语的专门性）。图4．1 显示该框架的关键元素，并在下面加以
简要描述。
关于过程工程界内正在开发的过程定义的概念，进一步阅读可参考文章“Software
Process Development and Enactment：Concepts and Definifions”"软件过程开发和规定：概念
和定义")[Feiler 92]。
4.3.2 与组织的软件过程财富有关的概念
组织的软件过程财富
(Organizations software
组织建立和维护一组如图4．1 所示的软件过程财富。这些软件过
程财富包括：
process assets ?? 组织标准软件过程咆括软件过程体系结构和软件过程元素），
?? 对批准使用的软件生存周期的描述，
?? 用手剪裁组织标准软件过程的指南和准则，
?? 组织的软件过程数据库，和
?? 软件过程有关文档库。
这些软件过程财富可以供项目在制定、维护和实施其自己定义的软
件过程时使用。组织能以多种方式组织软件过程财富，这取决于组
织建立其标准软件过程的方法。例如，软件生存周期的描述可以是
组织标准软件过程的一个主要部分。另一个例子是软件过程有关文
档库的一些部分可以存在组织的软件过程数据库中。
组织标准软件过程
Organizations standard
SOftware process
组织标准软件过程是基本过程的可操作的定义，基本过程指导在组
织中建立一个针对所有软件项目的共用的软件过程。标准软件过程
描述基本的软件过程元素，即预计每个项目都会纳入到其自己定义
的软件过程的过程元素。它也描述这些软件过程元素间的关系（例
如排序和界面）。它指导建立组织中所有软件开发和维护项目共用
的软件过程。
软件过程元素间的关系有时称为“软件过程体系结构”。
组织标准软件过程是项目定义软件过程的基础。它保证组织过程活
动的连续性，且是组织所用软件过程的测量和长期改进的依据。
Software process
architecture
软件过程体系结构是对组织标准软件过程的高层次（即概括的）描
述。它描述组织标准软件过程中软件过程元素的排序、界面、相互
依赖关系及其它关系。它也描述对于其它外部过程（例如，系统工
程、硬件工程和合同管理）的界面、依赖关系和其它的关系。
软件过程元素
Sortware process
element
软件过程元素是一个软件过程描述的构成元素。每个过程元素包括
一组妥善定义了的、有限制的、紧密相关的作业（例如，软件估计
元素、软件设计元素、编码元素及同行评审元素）。过程元素的描
述可以是待填充的样板、待完成的片段、待精炼的抽象、或待修改
的完整描述，或用过的无须修改的完整描述。
对批准使用的软件生
存周期的描述
Organizations
software process
assets
软件生存周期是一段时间，从设想软件产品的时间开始，到软件不
再能使用的时间为止。软件生存周期一般包括。概念阶段、需求阶
段、设计阶段、实现阶段、测试阶段、安装和调整阶段、运行和维
护阶段、以及有时还有退役阶段〔IEEE—STD－610〕
Description of
software life
cycles approved
for use
因为一个组织可能为各种多样签约的和（或）商业的顾客和用户生


地定义以致可认为是作业（虽然活动可以包括作业）。正因为如此，
在等级2 上避免使用“作业”一词，而采用不太严格的术语“活动”。
活动（Activities） 一个活动是为了实现某个目的所采取的任何步骤或所完成的任何
功能。既可以是脑力的也可以是体力的。活动包括经理和技术人员
为了完成项目和组织的作业所作的全部工作。
软件工作产品（项目结
果）Software work
Ptoducts (projet results
活动和作业的结果主要由软件工作产品组成。软件工作产品是作为
定义、维护或使用一个软件过程的一部分所生成的任何人工制品，
包括过程描述、计划、规程、计算机程序及其相连的文档。可以打
算也可以不打算将它们交付给顾客或最终用户。
工作产品成为过程中下一个步骤的输入，或者提供有关软件项目的
档案信息供未来项目使用。
软件工作产品的例子有：计划、估计、有关实际工作的数据、纠正
措施的文档和需求文档。其中可交付给顾客或最终用户的软件工作
产品的子集称作软件产品。
软件产品Software
products
软件产品是指定交付给顾客或最终用户的一套完整的计算机程序、
规程、以及相连的文档和数据，或者其中的任何独立的项、[IEEE
一STD～610]
所有的软件产品均是软件工作产品。可是不交付给顾客或最终用户
的软件工作产品不是软件产品。
4.3.4 项目定义软件过程和软件开发计划间的关系
一般项目定义软件过程的描述仍不够明确以致不能直接执行。虽然它一般标识出诸如角
色（即谁去执行一个作业）和执行作业所需的软件工作产品的类型等事项，但它并不规定承
担该角色的个人、将建立的具体的软件工作产品、也不规定执行作业和活动的进度。
项目软件开发计划在项目定义软件过程（将做什么及将如何做）和项目具体完成方式（例
如哪一个人将按照什么样的进度生产哪种软件工作产品）之间建立联系，该开发计划可以是
单个文件，也可以是一些计划的集合，总起来称为软件开发计划。项目定义软件过程和其软
件开发计划～起使得实际执行该过程成为可能。
4.3.5 生在周期和CMM
关键实践并不意味着限制软件生存周期的选择。已多次使用某一个特定软件生存周期的
人可能会在关键实践的组织和结构中察觉到该生存周期的元素。可是，并不存在鼓励或阻碍
使用任何特定软件生存周期的企图。
术语“阶段”用来指示软件项目工作的一种已定义的划分，但它并不与任何特定的软件
生存周期相联系。正如在关键实践中所用的那样，“阶段”可以指严格的序列阶段，也可以
指部分重叠的overlapping 和累接（iteractive）的阶段。
4.3.6 技术和CMM
关键实践既不要求也不反对特定的软件技术——诸如建立原型，面向对象设计，重用软
件需求、设计、代码、或其它成分。
4.3.7 文档和CMM
关键实践描述若干过程一有关文档，每一个复盖特定的内容范围。关键实践并不要求在
关键实践中命名的文档与组织或项目的实际工作产品间建立—一对应关系。也不打算对
DOD所规定的文档或诸如DOD—STD－2167A或IEEE软件标准等标准建立—一对应关系。
关键实践仅仅要求这些文档的适当的内容是组织或项目的书面工作产品的一部分。
从文档结构方面来看，关键实践中所提及的某个文档的内容可能是一个更大的文档的一
部分。例如，一个组织可以有一个包括软件风险管理计划要点的软件开发计划。
另一方面，关键实践中所提及的某个文档的内容可能分散在一组文档中，而此组文档不
同于该关键实践中所命名的那组文档。例如，一个项目可以编制三个文档：软件开发计划、
软件管理计划和项目工作分解结构，以便满足有关一个软件项目的软件风险管理、软件质量


保证及软件开发计划等多个关键实践。
4.3.8 过程数据的收集和分析
有关过程数据的收集和分析的关键实践经过各成熟度等级逐渐进化。
在等级2，数握主要与项目工作产品的规模、工作量和进度有关，并对每个项目分别加
以定义、收集和存储。数据经过非正式机制在项目间共享。
在等级3，每个项目有一个已定义的软件过程，它是组织标准软件过程经剪裁后的版本。
与每个项目定义软件过程有关的数据被采集和存储在组织的软件过程数据库中。虽然所采集
和存储的数据可能因项目而异，但在组织的软件过程数据库中，它们是很好定义了的。
在等级4，基于组织标准软件过程，组织确定一组标准的测量。所有项目均采集这组标
准的测量数据，同时还采集其它的项目一专有的数据，并将它们存储在组织的软件过程数据
库中。项目使用这些数据去定量地了解项目定义软件过程的过程性能，并用这些数据使过程
性能稳定。组织也使用这些数据去建立组织标准软件过程的过程能力基线。
在等级5，数据用于选择技术和过程的改进区域，规划这些改进，并评价这些改进对组
织过程能力的影响。
66
4.4 组织机构和角色
虽然CMM 力图不依赖任何特定的组织机构和模型，但是在阐述CMM的实践时必须一
致地使用与某种组织机构和角色有关的术语，而它们可能不同于任何具体组织所用的组织机
构和角色。以下几节描述在解释CMM关键实践时所必需的与组织、项目及角色有关的各种
概念。
4.4.1 组织的角色
一个角色是一项已定义的职责，它可能安排给一个或多个个人。在关键实践中常用以下
角色的描述：
经理（manager） 经理履行的任务包括：对在经理职责范围内进行作业和活动的个人
提供技术和管理方面的指导并进行控制。经理的传统职能包括在其
职责范围内进行策划、资源分配、组织、指导和控制。
高级经理
（senior manager）
级经理在组织的足够高的层次上履行管理任务，主要关注组织的长
期生存力，而不是短期的项目和合同关心的事项及压力。一般讲,
一个高级工程经理负责多个项目。高级经理也提供和保护用于软件
过程长期改进的资源（例如，软件工程过程组）。
高级管理者，当用在CMM 中时，能表示满足上述描述的任何经理，
直到且包括整个组织的头。当用在关键实践中，术语高级管理者应
该按关键过程区域及考虑中的项目和组织的上下文加以解释。为实
现关键过程区域的目标必须完成一些十分重要的领导和监督任务；
这里的意图就是要特别包括那些履行这些十分重要的任务所必须
的高级经理。
项目经理
（Project manager）
项目经理履行的任务是对整个项目的总体业务负责；项目经理是指
导、控制、管理和调整项目进行构造软件或硬件／软件系统工作的
个人，项目经理是最终向顾客负责的个人。
在面向项目的组织机构中，工作在同一个项目的大多数人应向项目
经理报告，尽管某些科目可能有一个矩阵式的报告关系。而在矩阵
式的组织机构中，可能仅业务职员只向项目经理报告，而工程组负
有一个矩阵式的报告关系。
项目软件经理
project software
manager
项目软件经理履行的任务是对项目的全部软件活动总负责。项目软
件经理是项目经理按软件约定与其打交道的个人，且是控制一个项
目的所有软件资源的个人。
一个项目的软件工程组应向项目软件经理报告，尽管某些活动——
例如工具开发——可以有一个矩阵式的报告关系。
在大型项目中，项目软件经理多半是二线、三线或四线经理。在小
型项目或只有单个项目的部门中，项目软件经理可能是～线软件经
理或可能在更高层次


一线软件经理
first-line
software manaae
一线软件经理履行的任务是对由软件工程师和其它有关人员组成
的一个机构单位（例如，一个部门或者项目组）的人员配置和活动
负直接管理责住（包括提供技术方向及对人员和薪金进行管理的功
能）。
软件作业领导
software taSK leadere
一个软件作业领导履行的任务是充当特定作业的技术组的领导者，
负有技术责任并向工作在该作业的职员提供技术方向。
软件作业领导通常和其它工作在该作业的人员一样向同一个一统
软件经理报告。
职员、软件工程职员、
个人
／staff,sOftware＼
＼Staff,individuals／
在CMM的不同的关键实践中描述了不同的技术角色，在CMM 中
采用几个术语去指示履行这些不同技术任务的个人。职员是包括作
业领导的一些个人，他们负责完成一项指派的功能，例如软件开发
或软件配置管理，但他们不是经理。
软件工程职员是软件技术人员（例如分析员、程序员和工程师），
包括软件作业领导，他们进行项目的软件开发和维护活动，但他们
不是经理。术语“个人”，当用在关键实践中时，由该词出现处的
上下文来定性和限定（例如参与管理软件子合同的个人）
对于其它的工程组，例如系统工程组或系统测试组，也能对其角色作出类似的分解。
在一个具体的项目或组织中，在这些角色和个人之间不必—一对应。一个人能完成多个
角色，或者一个角色可由若干个人承担。
例如，对于一个小的纯软件项目，一个人可以承担多到六个角色：系统工程的一线经理，
项目的系统工程经理，软件的一线经理、项目的软件经理、项目经理和软件配置管理经理。
对于略大一点的项目，一个人可以担当：系统工程的一线经理、项目的系统工程经理和项目
经理，而另一个人可以既是一线软件经理又是项目的软件经理。这两位经理可以在同一个二
线机构中，也可以在不同的二线机构中。
对于大项目，许多岗位，特别是管理岗位，多半由不同的个人承担。
4.4.2 组织机构
必须充分理解有关组织、项目和组的基本概念，以便恰当地解释能力成熟度模型的关键
实践。以下段落定义这些概念在CMM 中的用法：
组织（Organization） 一个组织是一个公司或其它实体（例如政府机构或军种）内的一个
单位，在其内部将许多项目作为一个整体加以管理。在一个组织中
的所有项目共有一个相同的顶层经理并遵守共同的方针
项目（Project） 项目是一项要求共同努力的任务，其目标是开发和（或）维护一个
具体的产品。产品可以包括硬件、软件和其它成分。一般项目有它
自己的投资、成本统计和交付时间表。
组（Group） 组是负责一组作业或活动的部门、经理和个人的集会。组的规模可
以变化：从～个受指派的习日全日制的单个个人，或几个从不同部
门指派来的非全日制的个人，直到几个全日制的个人。
下面描述在CMM 中通常提及的组：
软件工程组
Software engineering
group
软件工程组是负责一个项目的软件开发和维护活动（即需求分析、
设计、编码和测试）的个人（既有经理又有技术人员）的集团。
进行软件一有关工作的组，例如软件质量保证组、软件配置管理组
和软件工程过程组，不在软件工程组之列。这些组都是“其它软件
一有关组”。
软件一有关组
Software-relatea groups
软件一有关组是代表一种软件工程科目的个人（即有经理又有技术
人员）的集团，它支持但不直接负责软件开发和（或）维护。
软件工程科目的例子包括软件质量保证和软件配置管理。
软件工程过程组
Software engineering
process group
软件工程过程组是由专家组成的组，他们推进组织所采用的软件过
程的定义、维护和改进工作。在关键实践中，这个组通常指“负责
组织的软件过程活动的组”。
系统工程组System
engineering group
系统工程组是负责下列工作的个人（既有经理又有技术人员）的集
团：规定系统需求；将系统需求分配给硬件、软件和其它成分；规
定硬件、软件和其它成分之间的界面；以及监控这些成分的设计和
开发以保证它们符合其规格说明。
系统测试组系统测试组是一些负责策划和完成独立的软件系统测试的个人（既
（System test group） 有经理又有技术人员）的集团，测试的目的是为了确定软件产品是
否满足对它的要求。
软件质量保证组
Software guality
Assurance group
软件质量保证组是一些计划和实施项目的质量保证活动的个人（既
有经理又有技术人员）的集团，其工作的目的是保证软件过程的步
骤和标准得到遵守。有关软件质量保证的机构问题，在4.4.3 节中
讨论。
软件配置管理组
Sotrware Configuration
management group
软件配置管理组是一些负责策划、协调和实施软件项目的正式配置
管理活动的个人（既有经理又有技术人员）的集团。
培训组
（Training grouP）
培训组是一些负责协调和安排组织的培训活动的个人（既有经理又
有技术人员）的集团。通常这个组准备和讲授大多数的培训课程并
且协调其它培训方式的使用。

是哥哥的笔记吗？