验证1
高级管理者定期参与评审组织的缺陷预防活动。
高级管理者定期评审的主要目的是在合适的抽象层次上并以及时的方式了解和洞察
软件过程活动，评审间隔应满足组织的需要，只要已存在报告例外情况的合适机制，间
隔可以长。
这些评审包括：
1．主要缺陷类别和在这些类别中缺陷的频率分布的摘要。
2．主要措施类别和在这些类别中措施的频率分布的摘要。
3．为解决主要缺陷类别所采取的重要措施。
4．有关所建立的、未解决的、已完成的行动条款的概括的状态。
5．对于缺陷预防活动的有效性及由缺陷预防活动所得到节省的概述。
6．已完成的缺陷预防活动的实际成本和所计划的缺陷预防活动的预测成本。
验证2
项目经理既定期地也事件驱动地参与评审软件项目的缺陷预防活动。
参看软件项目跟踪和监督关键过程区域的验证2 以便找到包括项目管理者监督评审的
典型内容的实践。
验证3
软件质量保证组评审和（或）审计缺陷预防的活动和工作产品并报告其结果。
参看软件质量保证关键过程区域。
至少，评审和（或）审计要验证：
1．软件工程经理和技术人员受到关于其缺陷预防任务的培训1。
2．适当地举行作业开始会议和原因分析会议。
3．评审措施建议和实施行动条款的过程得到遵循。

验证1
高级管理者定期参与评审那些组织的技术改革管理活动。
高级管理者定期评审的主要目的是在合适的抽象层次上并以及时的方式了解和洞察软
件过程活动。评审间隔应满足组织的需要，只要已存在报告例外情况的合适机制，间隔可以
长。
这些评审：
1．总结技术改革管理活动。
2．识别需要的战略变化。
3．导致问题的解决。
4．导致在合适时批准对技术改革管理计划的修订。
验证2
软件质量保证组评审和（或）审计技术改革管理的活动和工作产品，并报告其结果。
参考软件质坦保证关键过程区域。
至少，评审和（或）审计查证：
1．技术改革管理的计划。
2．选择、购买和安装新技术的过程。

时间；
一每个报告周期所接收的软件过程改进建议的百分数；
一全部的更改活动，包括更改的数目、类型和规模；
一实施每项过程改进的效果与其规定目标相比较；
一组织的和项目的总体性能，包括有效性、质量和生产率，与其规定目标相比较；
一每个项目的总的生产率和软件质量的趋势；和
一与顾客满意度的指标有关的过程测量。
验证实施
验证1
高级管理者定期参加评审软件过程改进的活动。
高级管理者定期评审的主要目的是在合适的抽象层次上并以及时的方式了解和报软件
过程活动。评审间隔应该满足组织的需要，只要已存在报告例外情况的合适制，间隔可以长。
进行这些评审是为了：
1．总结参加过程改进活动的情况。
2．评估过程性能。
3．识别所需要的目标更改。
4．解决问题。
5．当合适时，批准对软件过程改进计划的修订。
验证2
软件质量保证组评审和（或）审计软件过程改进的活动和工作产品，并报告其结果。
参阅软件质量保证关键过程区域。
至少，评审和（或）审计要查证：
1．组织的软件过程改进计划的准备工作。
2．软件过程改进建议的倡议、提交、评审、批准和策划实施的过程。
3．过程测量符合软件过程描述的程度和反映实际性能的程度。
4．对组织标准软件过程和项目定义软件过程的更改建立文档、评审、批准、控制和传
播的过程。
5．软件过程改进活动被一致地测量和跟踪的程度。
6．实际软件过程改进性能实现计划和目标的程度。

及由于不完全的规格说明、在估计应用领域上缺乏经验等等所导致的很可能的对这些参数的
过低估计。
合同条款和条件（contract terms and conditions ）——合同规定的法律、金融和行政管理
方面。
关键计算机资源（critical computer resource）——据认为将是项目风险源的计算资源的
参数，因为对这些资源的潜在需求有可能超出可得到的量。例子包括目标计算机的存储容量
和行主计算机的磁盘空间。
关键路径（critical path）——为保持整个项目按进度进行必须按计划完成的项目的一
系列的相互依赖的作业。。
顾客（customer）——负责接收产品和批准付款给开发组织的个人或组织。
缺陷(defect）——系统或系统成分中的能造成它们无法实现其被要求有的功能的缺点。
如果在执行过程中遇到缺陷，它可能导致系统的失效。
缺陷密度（ defectdensity）——在一个产品中识别出的缺陷数目除以产品成分的规模（用
该产品的标准度量术语表示）。
缺陷预防（defectprevention）——与识别缺陷或潜在缺陷并预防它们被引入到产品有关
的活动。
缺陷根源（defectrootcause）——使缺陷得以引入的基础原因（例如过程不健全）。
已定义等级（definedlevel）——（见成熟度等级。）
已定义的软件过程（definedsoftwareprocess）——（见项目定义软件过程。）
相关项（dependencyitem）——一个个人或组必须向第二个个人或组提供的产品、行动
或信息，使得第二个个人或组能完成所计划的任务。
开发配置管理（developmentalconfigurationmanagemt）——运用技术上的和行政上的管
理去指定或控制那些软件和其相关的技术文档，它们定义一个软件工作产品在开发期间内不
断进化的配置。开发配置管理处在开发者的直接控制之下。置于开发配置管理之下的配置项
不是基线，虽然在其开发的某些点上，它们可能被基线化并置于基线配置管理之下。
偏差（deviation）——相对于适当的规范、计划、标准、规程或受评审的变量来说是显
著的或明显的偏离。
已文档化的规程（documentedprocedure）——（见规程）。
有放过程（effectiveprocess）——可特征化为实用的、巴文档化的、已实施的、经培训
的、已测量的和能改进的过程。（也可参见妥善一定义的过程。）
最终用户（enduser）——当系统安装在运行环境中时，那些将按照其预先设计的运行
用途而使用该系统的个人或组。
最终用户代表（enduserrepresentatives）——挑选出的能代表最终用户整体的最终用户
样本。
工程组（engineeringgroup）——代表一门工程学科的个人（包括经理和技术人员）的
集合。工程学科的例子包括系统工程、硬件工程、系统测试、软件工程、软件配置管理和软
件质量保证。
评价（evaluation）——（见软件能力评价）。
事件一驱动的评审或活动（event－drivenreview／activity）——基于项目中某个事件的
出现而执行的评审或活动（例如一项正式评审或一个软件生存周期阶段的完成）。（参看定期
评审成活动以作对照。）
发现（findings）——标识出调查范围内最重要的议题、问题或机会的一项评估、评价、
审计或评审所作出的结论。
一线软件经理（first－line software manager）——对由软件工程师和其它相关职员构成

附录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
软件工程组和其它软件一有关组的成员接受有关定量过程管理的目标和价值的定向培
训。
参看培训大纲关键过程区域。

?? 可重复南——已建立起基本的项目管理过程去跟踪成本、进度和功能性。为了在具
有类似应用问题的项目上能重复以前的成功，必要的过程纪律已到位。
?? 已定义组——在管理活动和工程活动两方面软件过程均已文档化、标准化，并且集
成到组织的标准软件过程。所有的项目均采用经批准的、组织标准软件过程的剪裁
版本去开发和维护软件。
?? 已管理级——已采集软件过程和产品质量的详尽度量。软件过程和产品均得到定量
的理解和控制。
?? 优化级——通过利用来自过程和对创新思想及技术的先导性试验的定量反馈信息，
使得连续过程改进或为可能。
成熟度提问单（ maturityquestionnaire）——～组关于软件过程的提问，它抽样检查CMM
的每个关键过程区域中的关键实践。它被用作为评价一个组织或项目可靠地执行软件过程的
能力的出发点。
度量单位（measure）——度量的一个单位（例如源代码行或者设计的文件页数〕。
度量（measurent)——某物的线数、容量、数量或总量（例如。300 源代码行或7 个设
计文件页）。
方法（method）——规则和判据的～个适度完整的集合，这些规则和判据建立起一种精
确的和可重复的进行作业并达到所希望结果的方式。
方法论（methodology）——一组方法、规程和标准的集合，它确定一套集成的开发某
产品的综合工程方法。
里程碑（milestone）——一个在预定时间发生的事件，某个人应对其负责，并且能用它
来测量进程。
非技术性要来（notechnicalrequirements）——影响和限定软件项目管理活动的协议、条
件和（或）合同条款。
运行软件（ operationalsoftware）——打算交付给顾客，配置在预定环境中在某个系统中
运行的软件。
优化级（optimizininglevel）——（见成熟度等级。）
组织（organization）——一个公司或其它实体（例如政府机关或军种）中的一个单位，
在其中对许多项目作为一个整体加以管理。一个组织内的所有项目共有一个共同的顶层经理
和共同的方针。
组织的测量大纲（organizatlon’smeasurementprogram）——一组相关的用以阐述组织
的测量需求的要素。它包括对全组织范围适用的测量的定义、收集组织测量数据的方法和实
践、分析组织测量数据的方法和实践、以及组织的测量目标。
组织的软件过程财富（organization’ssoftwareprcessassets）——一组实体的集合，它由
组织维护，供项目在制定、剪裁、维护和实施其软件过程时使用。这些软件过程财富一般包
括：
?? 组织标准软件过程，
?? 对批准使用的软件生存周期的描述，
?? 剪裁组织标准软件过程的指南和准则，
?? 组织的软件过程数据库，和
?? 软件过程一有关文档库。
任何一项组织认为在进行过程定义和维护活动方面有用的实体均可作为过程财富被包
括在内。
组织的软件过程数据库（organization’ssoftwaredatabase）——为收集有关软件过程及

其生成的软件工作产品的数据并使其可供使用而建立的数据库，特别当数据与组织标准软件
过程有关时。该数据库包含或者索引实际的测量数换和为理解测量数据及评估其合理性与适
用性所需要的相关信息。过程和工作产品的数据的例子包括：对软件规模、工作量和成本的
估计值；软件规模、工作量和成本和实际数据；生产率数据；同行评审的范围和效率；以及
在软件代码中所发现的缺陷的数目及严重性。
组织标准软件过程（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．确定所选出的软件过程改进建议实施的优先级。