附录A 参考文献附录B 术语汇编
执行能力（abilitytoperform）——（见共同特点）
验收准则（acceptancecriteria）——为了被用户、顾客或其它指定实体接收，一个系统
或成分必须满足的准则。IIEEE－STD610I
验收测试（accePtancetesting）——为确定一个系统是否满足其验收准则和为使得用户
能确定是否接收该系统而进行的正式测试。（IEEE －STD－610）
活动（activtity）——任何～个为实现某个目的而采取的步骤或所执行的功能，既可是
脑力的，也可是体力的。活动包括经理和技术人员为完成项目和组织的作业所进行的全部工
作。（对照参看作业）
执行的活动（activitiesperformed）——（见共同特点）
行动项（actionitem）——（1）已安排给某个个人或小组处理的事务清单中的一个单元。
（2）一项已被采纳的行动建议。
行动建议（action①ProPOsal）——作为缺陷预防活动的结果，一项已文档化的对过程
或过程一有关项的更改建议，它将预防将来再出现已识别出的缺陷。（也可参看软件过强改
进建议）
分配需求（allocatedrequirements）——（见分配给软件的系统需求）。
应用领域（applicationdomain）——一组有界限的相关系统（即处理一个特定类型问题
的那些系统）。在一个应用领域内的开发和维护工作通常要求专门的技能和（或）资源。例
如工资和人员系统、指挥和控制系统、编译程序和专家系统。
评估（assessment）——（见软件过程评估）
审计（andit）——对一个成一组工作产品所作的独立的考察，评估它们与规格说明、标
准、合同协议或其它判据的符合性。DEEE－STD－610〕
塞线(baseline）——已经过正式评审和认可，作为以后进一步开发的基础，并且只有通
过正式的更改控制规程才能进行更改的规格说明或产品。【IEEE－STD－610〕
基线配置管理（baselineconfigurationmagement）——建立经正式评审和认可并作为进
一步开发工作的基础的基线。某些诸如软件设计和代码这样的软件工作产品应该有在预
先确
定点上建立的基线，并且对这些项应该施加严格的更改控制过程。当与顾客打交道时，
这些
基线提供控制和稳定性。（也可参看基线管理。）
基线管理（baselinemanagement）——在配置管理中，运用技术上的和行政上的管理去
指
定一些文档和对这些文档的更改，这些文档在一个配置项的生存期内的某些特定时刻，
正式
标识出和建立起基线。DEEE－STW610〕
测定基准（ benchmark）——一项标准，对照它能进行测量或比较。【IEEE－STD－610〕
①译注：measurement 的翻译有两种，当与“软件”或“质量”相这时用度量，与“硬
件”或“过程”相这时用测量．
投标者（bidder）——一个个人、合作伙伴、公司或协会，他已提交一项提议，并且是
待签署的设计、开发和（或）制造一个或多个产品的合同的候选人。
能力成熟度技型（capabilitymaturitymodel）——对软件组织进化阶段的描述，随着软件
组织定义、实施、测量、控制和改进其软件过程，它们经过这些阶段逐步前进。该模型使得
确定当前过程能力的工作和识别对软件质量和过程改进最关键的问题变得容易，从而对选择
过程改进战略提供指导。
原因分析（causalanalysis）——为确定缺陷的根源所作的缺陷分析。
原因分析会议（causalanalysismeeting）——在完成一特定任务后为分析任务完成期间所
暴露的缺陷而举行的会议。
CMM——能力成熟度模型的首字母缩略词。
约定（commitment）——自由地接受的、可视的、期待各方遵守的协议。
执行约定（commitmenttoperform）——（见共同特点。）
缺陷的一段原因（commoncanse（ofadefect））——一种缺陷原因，这种缺陷原因是一个


过程或系统固有的。一般原因影响到过程的每个输出和工作在此过程中的每个人。（对照参
着特殊原因。）
共同特点（commonfeatures ）——用以进一步细分CMM 关键过程区域的类别。共同特
点是指示一个关键过程区域的实施和规范化是否是有效的、可重复的、和持久的一些属性。
CMM 的共同特点如下；
?? 执行约定——组织必须采取的保证过程得以建立和持续下去的行动。执行约定一般
涉及到组织方针的建立和高级管理者的支持。
?? 执行能力——为了适当地实施软件过程，项目或组织中必须存在的先决条件。执行
能力一般涉及资源、组织机构和培训。”
?? 执行的活动——对于那些为实施一个关键过程区域所必须的角色和规程的描述。执
行的活动一般涉及制定计划和规程，进行工作，跟踪它和必要时采取改正行动。
?? 测量①和分析——对过程进行测量和对测量结果进行分析的需求的描述。测量和分
析一般包括可能采取的旨在确定执行的活动的状态和有效性的测量例子。
?? 验证实施——保证活动按照已建立的过程进行的措施。进行验证一般包括管理者和
软件质量保证组作的评审和审计。
配置（configuration）——在配置管理中，软件或硬忏所具有的正如在技术文档中所陈
述的或产品所实现的那些功能特征和物理特征、[IEEE－STD-610〕
配置控制（configuration control）—一配置管理的一个构成部分，它包括在正式建立配
置项的配置标识之后对它们所作更改的评价、协调、批准或拒绝和实施。[IEEE－STD-610」
配置标识（configuration identification）——配置管理的一个构成部分，它包括为系统选
择配置项，并在技术文档中记录其功能特征和物理特征。[IEEE－STD-610]
配置项（configuration item）——指定为配置管理对象且在配置管理过程中作为单个实
体处理的硬件集合、软件集合或硬软件集合。[IEEE－STD-610]
配置管理（coniguration management）——对以下各项运用技术上和行政上的管理和监
视的一种学科：对一个配置项的功能特征和物理特征进行标识并写成文档；对这些特征的更
改进行控制；对重政处理过程和实施状态进行记录和报告；以及对规定需求的符合性进行验
证。
[IEEE－STD-610]
配置管理库系统（configuration management library system）——存取软件基线库内容的
工具和规程。
配置单元（configuration unit）——可放人配置管理库系统和从库中检索的一个配置项
或成分的最低层次的实体。
一致性（consistency）——在系统或其成分的文档或部件中，一致、标准化和无矛盾的
程度。[IEEE－STD－610]
偶然性因素（contingency factor）——对规模、成本或进度计划的调整（增加），以便计

执行能力
能力1
存在一个组负责实现组织的培训需求。
培训组的成员可能包括全日制或非全日制的来自本组织的指导者，也可能来自外部。一
个组是负责一组作业或活动的部门、经理和个人的集合。组的规模可以变化：从一个受指派
的非全日制的单个个人，到几个从不同部门指派来的非全日制的个人，到几个全日制的个人。
建立一个组时应考虑的方面包括指派的作业或活动、项目的规模、组织机构和组织文化。某
些组，例如软件质量保证组，集中注意力于项目的活动，而其它组，例如软件工程过程组，
集中关注全组织的活动。
能力2
为实施培训大纲提供足够的资源和投资。
培训大纲的要素的例子包括：
一组织的培训计划，
一培训材料，
一培训的展开或获得方法，
一培训的进行，
一培训设施，
一培训的评价，和
一培训记录的维护。
1．指派一个经理负责实施组织的培训大纲。
2．使得支持培训大纲活动的工具合用。
支持工具的例子有：
一工作站，
一教学的设计工具，
一数据库程序，和
一编写介绍材料的程序包。
3．使得适当的设施可用于进行培训。
课堂培训设施应和学生的工作环境分开以消除打扰。
在合适处，培训应在非常类似于实际性能条件的设置中进行，培训包括仿真实际工作情
况的活动。
能力3
培训组的成员具有完成其培训活动所需要的技能和知识。
提供这些技能和知识的方式的例子有。
一在教学技巧方面的培训，和
一在题材方面的知识更新培训。
能力4 软件经理接受有关培训大纲的定向培训。
执行的活动
活动1
每个软件项目制定和维护一个规定其培训需要的培训计划。
该计划包括：
l．所需要的一组技能及何时需要那些技能。
2．要求培训的技能和将经由其它载体获得的技能。
某些技能能有效地和效率高地通过非正式载体（例如非正式的培训和报告，阅读书和杂
志，“信手画谈”，午餐讨论会，在职培训和非正式的指导）加以传递；而另一些技能，要有
效地和效率高地传递就需要基于较正式的培训载体(例如，课堂培训，计算机辅助教学，有
指导的自学，使用便利的录像和正式的学生和教师计划）。
3·所要求的培训，被要求接受培训的人，及何时进行培训。
参考全部其它的关键过程区域中的执行能力共同特点以便找到特定培训需求的例子。
在合适处，对个人的培训与其工作职责紧密结合，使培训后的一段合理的时间内，在职
活动或其它外部的经历将增强培训。
4.将如何提供培训。
培训可以由软件项目、组织的培训组或一个外部组织提供。
适合软件项目完成的培训例子有：
—在项目特定的应用领域和要求方面的培训，
一在项目的软件体系结构方面的培训，和
—在项目层上能更有效地和更效率高地进行的其它培训。
活动2
?? 按照已文档化的规程制定和修正组织的培训计划。
该规程一般规定；
1．计划利用在软件项目培训计划中所指出的培训需求。
2．以组织所需要的技能及何时需要这些技能为根据，确定将提供的特定培训。
3．当合适时对组织的培训计划进行修订以纳入更改。
4.发表组织的培训阶划时和每当作出主要的修改时，受影响的个人评审该计划。
受影响的个人包括；
—高级管理者，
—软件经理，和
—软件一有关组的经理。
5．对组织的培训计划进行管理和控制。
“进行管理和控制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知的
（即版本控制），而且以受控的方式引进更改卿更改控制）。
如果希望有比“进行管理和控制”所蕴含的更高程度的控制，则工作产品可置于配置管
理的完备的纪律之下，正如在软件配置管理关键过程区域中所描述的。
6．对受影响的组和个人，组织的培训计划是易于利用的。
受影响的组和个人的例子有：
一高级管理者，
一培训组，
—软件—有关组的经理，
—软件工程组（包括全部小组，例如软件设计小组），
—软件估计组，
—系统工程组，
一系统测试组，
一软件质量保证组，
一软件配置管理组，
—合同管理组，和
一文档支持组。
活动3
?? 按照组织的培训计划进行组织的培训。
该计划包括；
1．组织内所需要的特定培训及何时需要。
2．将从外部源获得的培训和将由培训组提供的培训。
3．准备和进行培训或从外部获得培训所需要的资金和资源（包括职员、工具和设施）。
4．培训组将开发的培训课程中所使用的教材标准。
5．对于将由培训组开发的培训课程，其开发和修订的时间表。
6．进行培训的日程表，它以所预测的需要日期和预计的学生数为根据。
7．用于以下各项的规程：
?? 选择将接受培训的个人，
?? 注册和参加培训，
?? 保持所提供培训的记录，和
?? 收集、评审和使用对培训的评价及其它的培训反馈信息。
活动4
按照组织标准开发和维护在组织层上准备的培训课程。
这些标准要求：
1．编写对每个培训课程的描述。
该描述所阐述的专题的例子有：
一须计的听众，
—为参加培训所作的准备工作，
一培训目的，
一培训期的长度，
一课程计划，
—确定学生满意地完成学业的准则，
一定期评价培训有效性的规程，和
一特殊的考虑，例如：先导性试验或现场试验培训课程，更新培训的需要和后续
培训的机舍。
2．评审用于培训课程的材料。
评审培训材料的个人的例子有；
一训练专家，
一主题方面的专家，和
一待评审的培训课程先导试验期学员代表。
3．对培训课程的材料进行管理和控制。
活动5
制定免修所要求的培训应遵循的规程，并将其用于确定是否那些个人已具有履行其岗位
职责所要求的知识和技能。
活动6
保持培训记录。
1．保留所有成功地完成每个培训课程或其它经批准的培训活动的学生的记录。
2．保留所有成功地完成指定要求培训的学生的记录。
3．使得在考虑任命职员和经理时可以利用成功完成培训的记录。

定量过程管理
等级4（已管理的）的一个关键过程区域
定量过程管理的目的是定量地控制软件项目的过程性能。软件过程性能表示遵循一软件
过程所得到的实际结果。
定量过程管理包括建立集成软件管理关键过程区域所描述的项目定义软件过程的性能
目标、测量过程性能、分析这些测量结果并作出调整以保持过程性能在可接受的范围内。当
在可接受范围内过程性能是稳定时，项目定义软件过程、相关连的测量和测量的可接受范围
就作为基线建立起来，并被用来定量地控制过程性能。
组织从软件项目采集过程性能数据，并使用这些数据对组织过程定义关键过程区域所描
述的组织标准软件过程的过程能力（即，一个新项目能预计获得的过程性能）进行特征
描述。
过程能力描述从遵循一个软件过程所得到须期结果的范围（即，预计组织承担下一个软
件项目时最可能的输出）。软件项目采用这些过程能力数据来建立和修订其过程性能目标和
分析项目定义软件过程的性能。
目标
目标1
定量过程管理活动是有计划的。
目标2
项目定义软件过程的过程性能受到定量地控制。
目标3
组织标准软件过程的过程能力是定量地已知的。
执行约定
约定1
项目遵循书面的组织上关于测量和定量控制项目定义软件过程性能的方针。
该方针一般规定：
豆．为将项目定义软件过程置于定量控制之下，每个项目实施一个已文档化的计划。
术语“定量控制”的含意是指任何一项适用于分析软件过程、识别软件过程性能变化的
特殊原因、和将软件过程性能置于妥善定义的范围内的、定量的或基于统计的技术。
2．有关个人行为的敏感数据受到保护，并适当控制对这些数据的存取。
使用测量数据去评价个人，将对所报告的测量数据的正确性和有用性起不良影响。
约定2
组织遵循书面的有关分析组织标准软件过程的过程能力的方针。
该方针一般规定；
1．分析项目的过程性能测量结果以建立和维护组织标准软件过程的过程能力基线。
过程能力基线包括：
一组织标准软件过程的描述，
一测量的标准定义，和
一期望的测量值范围。
2．软件项目在建立其过程性能目标上使用组织标准软件过程的过程能力基线。
执行能力
能力1
存在一个负责协调组织的定量过程管理活动的组。
一个组是负责一组作业或活动的部门、经理、和个人的集会。组的规模可以变化：从一
个受指派的非全日制的单个个人，到几个从不同部门指派来的非全日制的个人，到几个全日
制的个人。建立一个组时考虑的因素包括指派的作业和活动、项目的规模、组织机构、和组
织的文化。某些组，例如软件质量保证组，集中注意力于项目的活动，而其它的组，例如软
件工程过程组，则集中关注全组织的活动。
1．这个组或者是负责组织软件过程活动的组（例如，软件工程过程组）的一部分，或
者它的活动与后者紧密地配合。
能力2
为定量过程管理活动提供足够的资源和投资。
1．软件工程组和其它软件一有关组的经理和作业领导执行项目定量过程管理活动。
软件一有关组的例子包括：
一软件质量保证组；
一软件配置管理组，和
一文档支持组。
2．存在全组织范围的测量大纲。
组织的测量大纲包括：
一定义全组织范围的测量，
一收集组织的测量数据，
一分析组织的测量数据，和
一组织的定量测量目标。
3．使得支持定量过程管理的工具合用。
支持工具的例子包括：
一软件源代码分析器；
一自动的测试范围分析器，
一数据库系统，
一定量分析程序包，和
一问题跟踪程序包。
能力3
对于已选择的过程和产品度量，具备对于收集、记录、和分析数据的支持。
在这些实践中所指的产品数据是在分析软件过程时所用的产品度量。
能力4
实施或支持定量过程管理的个人接受执行这些活动所要求的培训。
培训的例子包括：
一对软件过程建模和分析；
一对过程测量数据进行挑选、收集和确认；和
一使用基本的定量的方法和分析技术（例如，估计模型，Paret。图，和控制图）。
参看培训大钢关键过程区域。
能力5
软件工程组和其它软件一有关组的成员接受有关定量过程管理的目标和价值的定向培
训。
参看培训大纲关键过程区域。

其生成的软件工作产品的数据并使其可供使用而建立的数据库，特别当数据与组织标准软件
过程有关时。该数据库包含或者索引实际的测量数换和为理解测量数据及评估其合理性与适
用性所需要的相关信息。过程和工作产品的数据的例子包括：对软件规模、工作量和成本的
估计值；软件规模、工作量和成本和实际数据；生产率数据；同行评审的范围和效率；以及
在软件代码中所发现的缺陷的数目及严重性。
组织标准软件过程（organization’sstandardsoftwareprocess）——对于基本过程的可操
作的定义，基本过程指导在一个组织内的所有项目上建立一个共同的软件过程。它描述预期
每个软件项目的已定义软件过程均会包含的基本的软件过程元素。它还描述这些软件过程元
素间的关系（例如：排序和界面）。
定向培训（orientation）——向对在某专题领域内负责开展工作的个人进行监督或与这
些个人打交通的那些人进行的有关该专题的概述或介绍。（对照参看培训。）
Pareto 分析（Paretoanalysis）——通过将缺陷原因按从最重要到最不重要加以排序的方
法对缺陷进行分析。Pareto 分析基于以19 世纪经济学家VilfredoPareto 命名的原理，即绝大
多数后果起源于相对少的原因，也就是80％后果是由可能原因中的20％所遗成的。
同行评审（peerreview）——由一个软件工作产品生产者的同行遵循已定义的规程对产
品作的评审，目的在于识别出缺陷和改进之处。
同行评审领导（Peerreviewleade，）——一个经过专门培训并取得规划、组织和领导同
行评审资格的个人。
定期评审成活动（ periodicreview／activity）——在规定的固定时间间隔处出现的评审或
活动。（对照参看事件一驱动评审成活动）
方针（policy）——一种指导原则，一般由高级管理者制定，组织或项目采用它去影响
和决定决策。
主承包商（ primecontractor）——一个在行政上管理有关一个或多个产品的设计、开发、
和（或）维护工作的子合同的个人、合作伙伴、公司或协会。
规程(procedure）——对为完成一项给定作业将采取的行动步骤的书面描述。〔IEEESTD－
610）
过程（Process）——为了某个给定目的所执行的～系列步骤；例如，软件开发过程。[IEEE
－STO-610]
过程能力（prooes 。capability）——通过遵循一个过程能实现预期结果的程度。（对照
参见过程体验．〕
过程能力基线（ptocesscapabilitybaseline）——用文档记载的对在典型环境下由于遵循
某特定过程通常所能实现预期结果的范围的特性描述。一般在组织层上建立过程能力基线。
（参见过程性能基线以作对照。）
过提租据库（processdetabase）——（参见组织的软件过程数据库。）
过程描述（processdescriPtion）——对过程主要成分的可操作的定义。即以一种全面的、
精确的、可验证的方式规定～个过程的要求、设计、行为或其它特征的文档、它也可能包括
一些用以确定是否已满足上述特征的规程。在作业层、项目层或组织层上均可能有过程描述。
过程制定（process development）——定义和描述一个过程的行为。它可能包括策划、构造、
设计、实施和确认。
过程测量（processmeasurement）——一组定义、方法和活动，用来对一个过程及其产
生的产品进行测量以便对该过程进行特征描述和理解它。
过程性能（processperformance）——对遵循某过程所实现的实际结果的度量。（对照参
见过程能力。）
过程性能基线（processperformancebaseline）——用文档记载的对遵循一个过程所实现

测量和分析
测量1
进行测量并将测量结果用于确定软件产品的功能性和质量。
测量的例子有：
一在被跟踪的软件产品中积累统计和按阶段统计所识别出的缺陷的数目、类型和严重
性；和
一按类别（例如：保密性、系统配置、性能、和可靠性）总计的分配需求，和可追踪到
软件需求和系统测试用例的分配需求。
测量2
进行测量并将测量结果用于确定软件产品工程活动的状态。
测量的例子包括：
一在整个项目的生存期中每个分配需求的状态；
一按问题的严重性和它们存在的时间长度所作的问题报告；
一对分配需求的更改活动；
一对每个提议的更改进行分析的工作量和累计的更改分析总工作量；
一按类别（例如：界面、保密性、系统配置、性能和合用性）计算被纳入软件基线的更
改所需的数目；和
一用以实现和测试所采纳的更改所需的规模和成本，包括初始估计的和实际的规模和成
本。
验证实施
验证1
高级管理者定期参与评审软件产品工程的活动。
参考软件项目跟踪和监督关键过程区域的验证1 以便找到包括高级管理者监督评审的
典型内容的实践。
验证2
项目经理既定期地也事件驱动地参与评审软件产品工程的活动。
参考软件项目跟踪和监督关键过程区域的验证2 以便找到包括项目管理者监督评审的
典型内容的实践。
验证3
软件质量保证组评审和（或）审计软件产品工程的活动和工作产品，并报告其结果。
参考软件质量保证关键过程区域。
至少，评审和（或）审计要验证：
1．软件需求已被评审，保证它们是：
?? 完全的，
?? 正确的，
?? 一致的，
?? 可行的，和
?? 可测试的。
2．满足每个软件工程作业的准备就绪准则和完成准则。
3．软件产品符合对它们所规定的标准和要求。
4．完成所要求的测试。
5．按照已文档化的计划和规程，完成系统测试和验收测试。
6．正如在软件测试计划中所记载的那样，测试满足其验收准则。
7．已满意地完成和记录测试。
8．所检测出的问题和缺陷已记入文档，并进行了跟踪和解决。
9．执行了通过软件需求、设计、代码和测试用树对分配需求进行跟踪。
10．在软件产品交付给顾客或最终用户之前，对照软体基线和任何适用的分配需求，验
证了用于运行和维护软件的文档。

过程更改管理
等级5（优化的）的一个关键过程区域
过程更政管理的目的是本着改进软件质量、提高生产率和缩短产品开发周期的宗旨不断
改进组织中所用的软件过程。
过程更改管理包括定义过程改进目标，并且在高级管理者的支持下，在连续的基础上前
摄地（proactively）和系统地识别、评价和实施对组织标准软件过程和项目定义软件过程的
改进。
制定培训和鼓励性计划，使得组织中的每个人能够并鼓励他们参加过程改进活动。识别
改进的机会并评价其对组织的可能回报。在将过程更改纳入标准实践之前，进行先导性试验
以评估这些过程更改。
当软件过程改进经批准用于标准实践对，在合适时修订组织标准软件过程和项目定义软
件过程、在组织过程定义关键过程区域中能找到修订组织标准软件过程的实践，在集成软件
管理关键过程区域中能找到修订项目定义软件过程的实践。
目标
目标1
连续的过程改进是有计划的。
目标2
组织的软件过程改进活动的参与面是全组织范围的。
目标3
组织标准软件过程和项目定义软件过程被连续不断地改进。
执行约定
约定1
组织遵循书面的实施过程改进的方针。
该方针一般规定：
1．组织有定量的、可测的软件过程改进目标，并对照这些目标跟踪性能。
2．组织过程改进的方向是改善产品质量、提高生产率和缩短产品开发周期。
3．要求组织的全部职员和经理均参与改进软件过程的工作。
承认有技能的和有积极性的人是主要的过程改进资源。
约定2
高级管理者主办组织的软件过程改进活动。
高级管理者：
1．制定组织关于过程改进的长期目标和计划。
2．安排过程改进活动所需的资源。
3．与软件管理者协调，保证他们有合理的但又是进取的过程改进目标和旨在实现这些
目标的有效的过程改进计划。
4．对照目标监控过程改进行为。
5．在面临产品危机时，对过程改进保持一致的优先关注。
6．保证过程改进问题得到及时解决。
7．奖励参加过程改进活动的雇员。
执行能力
能力1
提供足够的用于软件过程改进活动的资源和投资。
1．为下列活动分配资源：
?? 领导、指导和支持过程改进活动；
?? 保持过程改进的记录；
?? 开发、控制和传播过程更改；和
?? 建立和运用行政管理职能和人类资源的职能，以便进行那些保持雇员更积极地
参与所必须的通信、激励和表彰活动。
2．可以得到在定义和分析软件过程方面有专门知识的有经验的个人，用来在组织的
过程改进活动中帮助组织。
3．使得支持过程改进的工具合用。
支持工具的例子有：
一统计分析工具，
—数据库系统，
一过程自动化工具，和
一过程建模工具。
能力2
软件经理接受所要求的在软件过程改进方面的培训。
培训的例子有：
一对技术上和组织上的更改进行管理，
一群组的建立，和
一适用于连续过程改进的群组工作技能。
参阅培训大纲关键过程区域。
能力3
软件工程组和其它软件一有关组的经理和技术人员接受所要求的在软件过程改进方面
的培训。
软件一有关组的例子包括：
一软件质量保证组，
一软件配置管理组，和
一文档支持组。
培训的例子有：
一质量和过程改进原理，和
一提议过程改进的规程。
参阅培训大纲关键过程区域。
能力4
高级管理者接受所要求的在软件过程改进方面的培训。
培训的例子有：
—基准测定（benchmarking）和比较性评价，
—过程改进原理，
一过程改进目标的设置和跟踪，和
—在连续的过程改进的环境中动力和群组的建立。
执行的活动
活动1
制定软件过程改进大纲，该大纲授权组织的成员改进组织的过程。


活动2
负责组织软件过程活动的组（例如，软件工程组）协调软件过程改进活动。
参着组织过程焦点关键过程区域以便找到包括负责组织软件过程改进活动的组的实践。
这个组：
1．确定组织的有关软件过程性能的目标和测量计划。
2．与高级管理者一起评审组织的过程性能目标以便得到他们的承认。
3．参加确定组织对过程改进的培训需求，支持编写与介绍培训课程材料。
参着培训大纲关键过程区域。
4．规定和维护处理过程改进建议的规程。
5．评审软件过程改进建议和协调有关这些建议的行动。
6．跟踪过程改进活动的状态，成就和参与情况，定期地向高级管理者报告结果。
7．协调和跟踪对组织标准软件过程的更改。
8．定义、建立和保持过程改进记录。
活动3
组织按照巴文档化的规程制定和维护软件过程改进计划。
参阅组织过程焦点关键过程区域的活动2，以便找到包括组织软件过程改进计划的实践
①。
这个规程一般规定：
1．软件过程改进计划基干：
?? 组织的经营和战略运作计划，和
?? 顾客满意程度的标记。
2．软件过程改进计划经历同行评审。
参看同行评审关键过程区域。
3．受影响的经理评审软件过程改进计划。
4．对软件过程改进计划进行管理和控制。
“进行管理和控制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知的
（即版本控制），而且以受控的方式引进更改（即更改控制）。
如果希望有比“进行管理和控制”所蕴含的更高程度的控制，则工作产品可置于配置管
理的完备纪律之下，正如在软件配置管理关键过程区域中所描述的。
活动4
依照软件过程改进计划进行软件过程改进活动。
该计划包括：
1．所要求的资源，包括人员和工具。
2．有最高优先组的过程改进区域。
3．有关软件过程性能和改进的可测的短期目标和长期目标。
4．致力于特定过程区域改进的群组和其任务。
群组的例子有；
—工作组，
一过程行动群组，和
一技术委员会。
5．关于以下各项的规程：
?? 高级管理者监督软件过程改进活动；
?? 软件经理策划和协调软件过程改进活动；
?? 个人和群组识别、评价和引进合适的软件过程改进；和
?? 群组展开对规定过程区域的软件过程改进。
6．为保持连续过程改进所要求的行政管理计划和支持计划。
?? 包括适当的旨在鼓励参与和促进软件过程改进活动的行政管理规模。
?? 在监督和评审软件过程改进活动中包括行政管理人员。
?? 认识到雇员对连续过程改进的作用和贡献。
活动5
按照已文档化的规程处理软件过程改进建议。
该规程一般规定：
1．提交软件过程改进建议。
软件过程改进建议可在任何时间提交，并可阐述软件过程的任何区域。
软件过程改进建议的来源的例子有：
一软件过程评估的发现和建议，
一组织的软件过程改进目标，
一对有关顾客问题和顾客满意度的数据的分析，
一对项目性能与软件质量目标和生产率目标相比较的数据的分析，
一过程基准测定的结果，
一过程／作业自动化的潜力，
一对有关缺陷原因的数据的分析，
一测量到的软件过程活动的有效性，
—一些被采用后获得成功的软件过程改进建议的例子，和
一当合适时，对以前提交的软件过程改进建议的反馈意见。
2．评价每项软件过程改进建议；对是否实施该建议作出决定，并将决策依据写成文档。
3．确定每项软件过程改进建议的预期效益。
预期得益区域的例子包括：
一生产率，
一质量，
一周期时间，
一顾客或最终用户满意度的其它标记，和
一任何其它的内部因素。
4．确定所选出的软件过程改进建议实施的优先级。