等级3 关键实践

组织过程焦点
等级3（已定义的）的一个关键过程区域
组织过程焦点的目的是建立组织对软件过程活动的责任，这些活动能改进组织的整体软
件过程能力。
组织过程焦点包括增进和保持对组织的和项目的软件过程的了解，协调那些评估、制定、
维护和改进这些过程的活动。
组织提供长期的保证和资源，通过诸如软件工程过程组那样的组来协调那些横跨当前和
未来软件项目的软件过程的制定和维护工作。这个组负责组织的软件过程活动，具体负责制
定和维护组织的标准软件过程和有关的过程财富（正如在组织过程定义关键过程区域中所描
述的），同时它和软件项目一起协调过程活动。
目标
目标1
在整个组织中，过程的制定和改进活动是协调的。
目标2
已标识出所使用的软件过程与一个过程标准相比的强处和弱点。
目标3
组织层上过程的制定和改进活动是有计划的。
执行约定
约定1
组织遵循书面的用以协调整个组织中的软件过程的制订和改进活动的组织方针。
该方针一般规定：
1、建立一个组，它负责组织层上的软件过程活动以及与项目协调这些活动。
2、定期评估项目所使用的软件过程以确定其强处和弱点。
3、项目所使用的软件过程是由组织的标准软件过程经适当剪裁而来。
参考集成软件管理关键过程区域的活动1 以便找到包括剪裁组织标准软件过程的实践。
4、对于每个项目的软件过程、工具和方法的改进及其它有用的信息，其它项目都可以
得到。
约定2
高级管理者主办组织的软件过程制定和改进活动。
高级管理者；
1、对组织的职员和经理表明他对这些软件过程活动的承诺。
2、制定关于投资、人员配置和其它资源的长期规划和约定。
3、制定管理和实施有关过程制定和改进活动的策略。
约定3
高级管理者监督组织的有关软件过程制定和改进的活动。
高级管理者：
1、保证组织的标准软件过程支持它的经营目标和战略。
2、就设置软件过程制定和改进的优先组问题提出建议。
3、参与制定用于软件过程制定和改进的计划。
?? 高级管理者同较高层次的职员和经理协调软件过程需求和问题。
?? 高级管理者与组织的经理协商以保证得到经理和职员的支持和参与。
执行能力
能力1
存在负责组织的软件过程活动的组。
一个组是负责一组作业或活动的部门、经理和个人的集合。组的规模可以变化：从一个
受指派的非全日制的单个个人，到几个从不同部门指派来的非全日制的个人，到几个全日制
的个人。建立一个组时应考虑的方面包括指派的作业和活动、项目的规模、组织机构和组织
文化。某些组，例如软件质量保证组，集中注意力于项目的活动，而其它的组，例如软件工
程过程组，集中关注全组织的活动。
1、在可能处，该组配备有一个软件技术专业人员的核心，指定这些专业人员为该组的
全日制职员，他们可能还要得到其它一些非全日制职员的支持。
该组的最常见的例子是软件工程过程组（SEPG）。
2、这个组的人员配置能代表软件工程学科和软件一有关学科。
软件工程和软件一有关学科的例子有：
一软件需求分析，
～软件设计，
～编码，
～软件测试，
～软件配置管理，和
一软件质量保证。
能力2
提供足够的用于组织软件过程活动的资源和投资。
1、责成具有特定领域专长的有经验的个人承担支持该组的任务。
特定领域的例子有：
一软件重用，
一计算机辅助软件工程（CASE）技术，
一测量，和
一培训课程的编制。
2、支持组织软件过程活动的工具是合用的。
支持工具的例子有：
一统计分析工具，
一桌面出版工具，
一数据库管理系统，和


一过程建模工具。
能力3
负责组织的软件过程活动的组员接受为完成这些活动所要求的培训。
培训的例子有；
一软件工程实践，
一过程控制技术，
一组织的更改管理，
一策划、管理和监控软件过程，和
一技术转换。
参考培训大纲关键过程区域。
能力4
软件工程组和其它软件一有关组的成员接受有关组织的软件过程活动及他们在这些’活
动中的角色的定向培训。
参考培训大纲关键过程区域。
执行的活动
活动1
定期地评估软件过程，制定处理评估发现的行动计划。一般每隔1—1 年半到每隔三年
进行一次评估。评估应察看组织中所用的全部软件过程，但可以通过采样过程区域和项目来
完成它。
评估组织软件过程能力的方法的一个例子是SEI 软件过程评估方法。
行动计划确定；
一将处理哪一项评估发现，
一实施更改的指南，这些更改处理评估所发现的问题，和
一负责实施更改的组或个人。
活动2
组织制订和维护用于其软件过程制定和改进活动的计划。
该计划：
1、采用根据软件过程评估和其它组织改进倡议所制定的行动计划作为主要输入。
2、定义待进行的活动和这些活动的时间表。
3、规定负责这些活动的组及个人。
4、确定所要求的资源，包括职员和工具。
5、当首次发行时及每当作出主要修改时，经受同行评审。
参考同行评审关键过程区域。
6、受到组织的软件经理和高级经理的评审和认同。
活动3
在组织层上协调组织和项目制定及改进其软件过程的活动。
这项协调包括对以下各项的制定和改进：
1、组织的标准软件过程。
参考组织过程定义关键过程区域的活动1 和2 以便找到包括组织标准软件过程的实践。
2、项目定义软件过程。
参考集成软件管理关键过程区域的活动1 和2 以便找到包括项目定义软件过程的实践。
活动4
在组织层上协调组织的软件过程数据库的使用。
组织的软件过程数据库用来收集有关组织和项目的软件过程及由此产生的软件产品的
信息。
参考组织过程定义关键过程区域的活动5 以便找到包括组织的软件过程数据库的实践。
活动5
对组织中限制使用的新的过程、方法和工具进行监控和评价，并当合适时，将其推广到
组织的其它部分。
活动6
在整个组织内协调有关组织和项目的软件过程的培训。
1．制定与组织和项目的软件过程有关的专题培训计划。
2．当合适时，可以由负责组织的软件过程活动的组（例如软件工程过程组）或培训织
准备和进行培训。
参考培训大纲关键过程区域。
活动7
将组织和项目的有关软件过程制定和改进的活动通知与实施软件过程有关的组。
通知这些人和使这些人介入的方法的例子有：
一关于过程的电子布告栏，
一过程咨询委员会，
一工作组，
一信息交流会，
一述评，
一过程改进群组（team），和
一非正式的讨论。
测量和分析
测量1
进行测量并将测量结果用于确定组织的过程制定和改进活动的状态。
测量的例子有：
一在组织的有关过程的评估、制定、改进的活动中所完成的工作、化费的工作量
和消耗的资金与有关这些活动的计划相比较；和
一每次软件过程评估的结果，和以前评估的结果和建议相比较。
验证实施
验证1
高级管理者定期参与评审有关软件过程制定和改进的活动。
高级管理者定期评审的主要目的是在合适的抽象层次上并以及时的方式了解和洞察软
件过程活动。评审间隔应该满足组织的需要，只要已存在报告例外情况的合适机制，间隔可
以长。
1．对照计划评审有关制定和改进软件过程的活动进展和状态。
2．分析在较低层次上无法解决的矛盾和问题。
3．对行动条款进行安排和评审，并跟踪至结束。
4．准备每次评审的摘要报告，并将其散发给受影响的组和个人。

软件质量保证
等级2（可重复的）的一个关键过程区域
软件质量保证的目的是向管理者提供适当的对软件项目正使用的过程和正构造产品的
可视性。
软件质量保证包括评审和审计软件产品和活动以验证它们符合适用的规程和标准，给项
目和其它有关的经理提供这些评审和审计的结果。
在软件项目的早期阶段，软件质量保证组与软件项目一起工作制定计划、标准和规程等，
这些计划、标准、和规程将增加软件项目的价值并将满足项目和组织方针上的限制。通过参
与制定计划、标准和规程，软件质量保证组帮助确保它们适合项目的需要，并且帮助验证它
们对完成整个软件生存周期中的评审和审计将是适用的。软件质量保证组在整个生存周期评
审项目活动，审计软件工作产品，并就软件项目是否正遵守已制定的计划、标准和规程等给
管理者提供可视性。
首先在软件项目内部处理符合性问题，如可能的话就地解决它。对于那些无法在软件项
目内部解决的问题，软件质量保证组逐级上递该问题到管理者的恰当层次以求得解决。
这个关键过程区域只包括该组履行软件质量保证功能的实践。而识别软件质量保证组要
评审和（或）审计的具体的活动和工作产品的实践一般包含在其它关键过程区域的验证实施
共同特点中。
目标
目标1
软件质量保证活动是有计划的。
目标2
软件产品和活动遵守适用的标准、规程和需求的情况得到客观的验证。
目标3
受影响的组和个人接到软件质量保证活动和结果的通知。
目标4
高级管理者处理在软件项目内部不能解决的不符合问题。
执行约定
约定1
项目遵循书面的实施软件质量保证（SQA）的组织方针。
该方针一般规定；
1、对全部软件项目，SQA 功能到位。
2、SQA 有一个向高级管理者报告的渠道，它独立于：
?? 项目经理，
?? 项目的软件工程组，和
?? 其它的软件一有关组。
其它软件一有关组的例子有：
一软件配置管理组，和
一文档支持组。
组织必须确定一种组织机构，它在组织的战略经营目标和经营环境的上下文中支持那些
要求独立性的活动，例如SQA。
独立性应该：
一给担当SQA 角色的个人提供组织上的自由度，使他们成为高级管理者在软件项目上
的“耳目”。
一使得担当SQA 角色的个人免受他们正在评审的软件项目的管理者所作的性能评价的
影响。
一使高级管理者相信正在报告的有关项目过程和产品的信息是客观的。
3、高级管理者定期地评审SQA 活动和结果。
执行能力
能力1
存在负责协调和实施项目的SQA 的组（即SQA 组）。
一个组是负责一组作业或活动的部门、经理、和个人的集合。组的规模可以变化，从一
个受指派的非全日制的单个个人，到几个从不同部门指派来的非全日制的个人，到几个全日
制的个人。建立一个组时应考虑的因素包括指派的作业和活动、项目的规模、组织机构和组
织的文化。某些组，例如软件质量保证组，集中注意力于项目活动，而其它组，例如软件工
程过程组，则集中关注全组织的活动。
能力2
为进行SQA 活动提供足够的资源和投资。
1、指派一个经理专门负责项目的SQA 活动。
2、指派一个在SQA 任务方面是博学的，并有权力采取适当的监督行动的高级经理接收
和处理软件不符合问题。
在SQA向高级经理报告链上的全部经理均是在SQA的任务、责任和权力方面有见识的。
3、使得支持SQA 活动的工具合用。
支持工具的例子有：
一工作站，
—数据库程序，
一电子表格程序，和
一审计工具。
能力3
SQA 组的成员受到培训以完成他们的SQA 活动。


培训的例子有：
一软件工程技巧和实践；
一软件工程组和其它软件一有关组的岗位任务及职责；
一用于软件项目的标准、规程和方法；
一软件项目的应用领域；
－SQA 的对象。规程和方法；
－SQA 组对软件活动的参与；
一SQA 方法和工具的有效使用；和
一人员间的交流。
能力4
软件项目的成员接受有关SQA 组的任务、职责、权力和价值等的定向培训。
执行的活动
活动1 按照已建档的规程为软件项目制订SQA 计划。
该规程一般规定：
1、SQA 计划的制定是在整个项目策划的早期阶段，并平行于整个项目策划。
2、受影响的组和个人评审该SQA 计划。
受影响的组及个人的例子有：
一项目软件经理；
一其它软件经理；
一项目经理；
一顾客的SQA 代表；
一SQA 组对其报告不符合问题的高级经理；和
一软件工程组（包括全部小组，诸如软件设计小组及软件作业领导）。
3、对SQA 计划进行管理和控制。
“进行管理和控制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知的
（即版本控制），而且以受控的方式引进更改（即更改控制）。
如果希望有比“进行管理和控制”所蕴含的更高程度的控制，则工作产品可置于配置管
理的完备的纪律之下，正如在软件配置管理关键过程区域中所描述的。
活动2
按照SQA 计划进行SQA 组的活动。
该计划包括：
1、SQA 组的职责和权力。
ZSQA 组的资源要求（包括职员、工具和设施）。
3、项目的SQA 组活动的进度表和投资。
4、SQA 组参加制定项目的软件开发计划、标准和规程的情况。
5、将由SQA 完成的评价。
待评价的产品和活动的例子有：
一运行软件和支持软件，
一可交付的和不交付的产品，
一软件和非软件产品（例如文档），
一产品开发和产品验证活动（例如运行测试用树），和
一生成产品时所从事的活动。
6、将由SQA 组进行的审计和评审。
7、将用作SQA 组评审和审计的基础的项目的标准和规程。
8、用于对不符合性问题建立文档和进行跟踪直至结束的规程。
这些规程可能作为计划的一部分而纳入，也可以通过索引那些包含它们的其它文档的方
式而纳入。
9、要求SQA 组生成的文档。
10、就SQA 活动给软件工程组和其它软件一有关组提供反馈信息的方法和频率。
活动3
SQA 组参与准备和评审项目的软件开发计划、标准和规程。
L、SQA 就以下几个方面对计划、标准和规程提供咨询和评审：
?? 对组织方针的符合性，
?? 对外部强加的标准和要求的符合性（例如工作陈述所要求的标准），
?? 适合项目使用的标准，
?? 在软件开发计划中应阐述的专题，和
?? 项目指定的其它领域。
2、SQA 组验证计划、标准和规程已到位并可用于评审与审计软件项目。
活动4
SQA 组评审软件工程活动以验证符合性。
1、对照软件开发计划和指定的软件标准和规程去评价活动。
参考其它关键过程区域中的验证实施共同特点以便找到包括由SQA 组进行特定评审和
审计的实践。
2、对偏差进行鉴别和建立文档，并跟踪到结束。
3、验证纠正措施。
活动5
SQA 组审计指定的软件工作产品以验证符合性。
1、在交付给顾客之前，评价可交付的软件产品。
2、对照指定的软件标准、规程和合同要求评价软件工作产品。
3、对偏差进行鉴别和建立文档，并跟踪到结束。
4、验证纠正措施。
活动6
SQA 组定期向软件工程组报告其活动的结果。
活动7
按照巴文档化的规程对在软件活动和软件工作产品中所鉴别出的偏差建立文档并加以
处理。
该规程一般规定：
1、将不符合软件开发计划和指定的项目标准及规程的问题写成文档，并在可能处，与
适当的软件作业领导、软件经理或项目经理一起，加以解决。
2、有些不符合软件开发计划和指定的标准及规程的问题不能与软件作业领导、软件经
理或项目经理一起加以解决，将这些不符合问题写成文档并提交给指定的接收不符合问题的
高级经理。
3、定期评审提交给高级经理的不符合问题直至解决它们为止。
4、对不符合问题的文档进行管理和控制。
活动8
当合适时，SQA 组与顾客的SQA 人员一起对它的活动和发现进行定期评审。

培训大纲
等级3（已定义的）的一个关键过程区域
培训大纲关键过程区域的目的是培育个人的技能和知识，使他们能有效地和效率高地履
行其职责。
培训大纲首先分别识别出组织、项目和个人所需要的培训，然后展开或设法获得培训以
满足所识别的需求。
每个软件项目评价它当前的和未来的技能需求，并决定如何才能获得这些技能。某些技
能可有效地和效率高地通过非正式的载体传递（例如在职培训和非正式指导），而其它的技
能则需要较正式的培训载体（例如课堂培训和受指导的自学）才能有效地和效率高地传递。
必须选择和使用恰当的载体。
这个关键过程区域仅包括培训组完成培训功能的实践，而识别特定培训专题卿所需要的
知识或技能）的实践则包含在各个有关的关键过程区域的执行能力共同特点中。
目标
目标1
培训活动是有计划的。
目标2
提供用以培育为履行软件管理和技术角色所需要的技能和知识的培训。
目标3
软件工程组和软件一有关组中的个人受到履行其角色所必须的培训。
执行约定
约定1
组织遵循书面的满足其培训需要的方针。
该方针一般规定：
1．识别每个软件管理和技术角色所需的技能和知识。
2．识别和批准传递技能和知识的培训载体。
经批准的培训载体的例子有；
—课堂培训，
一计算机辅助教学，
一受指导的自学，
一正式的学徒和教练计划，和
?? —使用便利的录像。
人提供培训以建立组织的技能基础，满足项目的特定需求和培育个人的技能。
4．可在组织内展开培训或当合适时从组织外获得培训。
外部培训源的例子有：
一顾客提供的培训，
一商业上现有的培训课程，
一科学计划，
一专业性会议，和
一讨论班。

软件配置管理
等级2（可重复的）的一个关键过程区域
软件配置管理的目的是建立和维护在项目的整个软件生存周期中软件项目产品的完整
性。
软件配置管理包括标识在给定时间点上软件的配置（即选定的软件工作产品及其描述），
系统地控制对配置的更改、并维护在整个软件生存周期中配置的完整性和可银踝性。置于软
件配置管理之下的工作产品包括交付给顾客的软件产品（例如软件需求文档和代码），以及
与这些软件产品等同的产品项或生成这些软件产品所要求的产品项（例如编译程序)建立一
个软件基线库，当软件基线形成时就将它们纳入该库。通过软件配置管理的更改控制和配置
审计功能，系统地控制基线的更改和那些利用软件基线库构造成的软件产品的发行。
这个关键过程区域仅包括实施软件配置管理功能的实践。而标识具体的配置项或单元的
实践则包含在描述每个配置项或单元的开发和维护的关键过程区域中。
目标
目标1
软件配置管理活动是有计划的。
目标2
所选定的软件工作产品是巳标识的、受控的和适用的。
目标3
对巴标识的软件工作产品的更改是受控的。
目标4
受影响的组和个人得到软件基线的状态和内容的通知。
执行约定
约定1
项目遵循书面的用以实施软件配置管理（SCM）的组织方针。
该方针一般规定；
1、明确指派每个项目的SCM 职责。
2、在项目的整个生存周期内实行SCM。
3、对于对外可交付的软件产品、指定的内部软件工作产品和指定在项目内部使用的支
持工具（例如编译器）都实行SCM。
4、项目建立或可以利用一个仓库，用来存储配置项／单元和相关联的SCM 记录。
在这些实践中这个仓库的内容称为“软件基线库”。
存取该仓库的工具和规程在这些实践中称为“配置管理库系统”。
置于配置管理之下并作为单个实体予以处理的工作产品称为配置项。配置项一般分解为
配置成分，而配置成分一般分解为单元。在一个硬件／软件系统中，所有的软件可看成一个
单个配置项，或者可将该软件分解为多个配置项。在这些实践中术语“配置项牌元”用于指
示在配置管理下的元素。
5、定期审计软件基线和SCM 活动。
执行能力
能力1
存在或者建立一个有权力管理项目软件基线的委员会（即软件配置控制委员会一
SCCB）。
该SCCB：
1、审定软件基线的建立和配置项／单元的标识。
2、代表项目经理和所有可能受到软件基线更改影响的组的利益。
受影响的组的例子有；
一硬件质量保证组，
—硬件技术状态（配置）管理组，
一硬件工程组，
一制造工程组，
一软件工程组（包括所有的小组，例如软件设计小组），
—系统工程组，
一系统测试组，
一软件质量保证组，
—软件配置管理组，
一合同管理组，和
一文档支持组。
3、评审和审定对软件基线的更改。
4、审定由软件基线库制造的产品的生成。
能力2
存在负责协调和实施项目的SCM 的组（即SCM 组）。
一个组是负责一组作业或活动的部门、经理、和个人的集合。组的规模可以变化：从一
个受指派的非全日制的单个个人，到几个从不同部门指派来的非全日制的个人，到几个全日
制的个人。建立一个组时应考虑的问题有：指派的作业和活动、项目的规模、组织机构和组
织文化。某些组，例如软件质量保证组，集中注意力于项目的活动，而其它组，例如软件工
程过程组，集中关注全组织的活动。
SCM 组协调或实现：
1、项目的软件基线库的生成和管理。
2、SCM 计划、标准和规程的制定、维护和散发。
3、将置于SCM 之下的软件工作产品集会的标识。
一个工作产品是由定义、维护、或使用一个软件过程所生成的任何人工制品。


4、对存取软件基线库的管理。
5、软件基线的更新。
6、由软件基线库制造的产品的生成。
7、SCM 行动的记录。
8、SCM 报告的生成和散发。
能力3
为进行SCM 活动提供足够的资源和投资。
1、安排一个经理专门负责SCM。
2、使得支持SCM 活动的工具合用。
支持工具的例子有：
一工作站，
一数据库程序，和一
一配置管理工具。
能力4
SCM 组的成员在有关进行其SCM 活动的对象、规程和方法方面受到培训。
培训的例子包括：
一SCM 标准、规程和方法；和
一SCMXi 具。
能力5
软件工程组和其它软件一有关组的成员受到培训以便完成其SCM 活动。
其它软件一有关组的例子有：
～软件质量保证组，和
一文档支持组。
培训的例子有：
一在软件工程组和其它软件一有关组的内部进行SCM 活动要遵循的标准、规程和方法，
和
一SCM 组的角色、职责和权力。
执行的活动
活动1
按照已文档化的规程对每个软件项目准备一份SCM 计划。
这个规程一般规定：
1、SCM 计划的制定是在整个项目策划的早期阶段，并平行于整个项目策划。
2、受影响的组评审SCM 计划。
3、对SCM 计划进行管理和控制。
“进行管理和控制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知的
（即版本控制），而且以受控的方式引进更改（即更改控制）。
如果希望有比“进行管理和控制”所蕴含的更高程度的控制，则工作产品可置于配置管
理的完备的纪律之下，正如在本关键过程区域中所描述的。
活动2
用已文档化的经批准的SCM 计划作为进行SCM 活动的基础。
该计划包括：
1、将进行的SCM 活动、活动的日程表、指派的职责和所要求的资源（包括职员、工
具和计算机设施）。
2、SCM 需求和将由软件工程组及其它软件一有关组进行的SCM 活动。
活动3
建立一个配置管理库系统作为软件基线的仓库。
该库系统：
l、支持SCM 的多个控制层次。
导致多个控制层次的情况例如：
一在生存周期的不同时间所需要的控制层次不同（例如，随着产品成熟要更加严密的控
制），
一纯软件系统和既包括硬件又包括软件的系统所需要的控制层次不同。
2、提供对配置项／单元的存储和检索功能。
3、在受影响的组之间和在库内部的控制层次之间提供配置项／单元的共享和传送。
4、帮助使用配置项／单元的产品标准。
5、对配置项／单元的归档版本提供存储和恢复功能。
6、帮助保证由软件基线库制造的产品的正确生成。
7、对SCM 记录提供存储、更新和检察功能。
8、支持SCM 报告的编制。
9、提供对库结构和内容的维护。
库维护功能的例子有：
一库文件的备份／重建，和
一从库的错误中恢复。
活动4
标识将置于配置管理之下的软件工作产品。
1、基于已文档化的准则选择配置项／单元。
可标识为配置项／单元的软件工作产品的例子有：
一过程一有关文档（例如：计划、标准或规程），
一软件需求，
一软件设计，
一软件代码单元，
～软件测试规程，
～为软件测试活动所构造的软件系统，
一为交付给顾客或最终用户所构造的软件系统，
一编译程序，和
一其它支持工具。
2、安排给每个配置项／单元唯一的标志符。
3、详细说明每个配置项／单元的特征。
4、详细说明每个配置项／单元所属于的软件基线。
5、详细说明在开发中将每个配置项／单元置于配置管理之下的时间点。
6、标识每个配置项／单元的负责人（即从配置管理的角度来说的所有者）。


个关键过程区域
组织过程定义的目的是开发和维护～组便于使用的软件过程财富，这些财富改进横跨各
项目的过程性能，并为组织积累性的长期得益打下基础。
组织过程定义包括制定和维护组织的标准软件过程，以及相关的过程财富，例如：软件
生存周期的描述，过程剪裁指南和准则，组织软件过程数据库和软件过程一有关文档库。
这些财富能以多种方式汇集，取决于对组织过程定义的组织实施。例如软件生存周期的
描述可以是组织标准软件过程的一个必备部分，或者软件过程一有关文档库的某些部分可以
存储在组织软件过程数据库中。
在开发、实施和维护项目定义软件过程中，可以使用组织软件过程财富。(与项目定义
软件过程的制定和维护有关的实践在集成软件管理关键过程区域中加以描述。)
目标
目标1
制定和维护组织的标准软件过程。
目标2
收集和评审有关软件项目使用组织标准软件过程的信息，并使其合用。
执行约定
约定1
组织遵循书面的制定和维护标准软件过程及相关过程财富的方针。
组织的软件过程财富包括：
一组织的标准软件过程，
一关于项目剪裁组织标准软件过程的指南和准则，
一对批准使用的软件生存周期的描述，
一组织的软件过程数据库，和
一以前开发的、适合重用的软件过程一有关文档的库。
这个方针一般规定：
1．标准软件过程是对组织定义的。
标准软件过程的主要目的是在项目间能最大限度地共享过程财富和经验，并使得能在组
织层上定义和聚集各项目共用的一组标准的过程测量。
组织标准软件过程可以包含多种软件过。因为软件项目可以以多种方式组织应用、生存
周期、方法论和工具，所以为了阐述对不同应用领域、生存周期、方法论和工具的需要，就
可能需要多种软件过程。
2．项目定义软件过程是组织标准软件过程经剪裁的版本。
参考集成软件管理关键过程区域的活动1 以便找到剪裁组织标准软件过程的实践。
3．组织的软件过程财富得到维护。
4．对从各个项目收集来的信息加以组织，并用于改进组织的标准软件过程。
所收集的信息的例子有：
一过程和产品测量，
一经验教训，和
一其它过程一有关的文档。
执行能力
能力1
为制定和维护组织的标准软件过程和有关过程财富提供足够的资源和投资。
1．负责组织软件过程活动的组（例如软件工程过程组）完成或协调组织标准软件过程
及有关过程财富的开发和维护。
参考组织过程焦点关键过程区域以便找到包括负责组织软件过程活动的组的实践。
2．使得支持过程的开发和维护的工具合用。
支持工具的例子有：
一桌面出版工具，
一数据库管理系统，和
一过程建模工具。
能力2
制定和维护组织的标准软件过程和有关过程财富的个人受到为完成这些活动所要求的
培训。
培训的例子有：
一软件工程实践和方法，
一过程分析和建立文档的方法，和
一过程建模。
参考培训大纲关键过程区域。
执行的活动
活动1
按照已文档化的规程制定和维护组织的标准软件过程。
该规程一般规定：
1．组织的标准软件过程符合（当合适时）强加给组织的软件方针、过程标准和产品标
准。
2．组织的标准软件过程满足（当合适时）通常由其顾客要求项目遵守的软件过程标准
和产品标准。
3．当合适时，将最先进的软件工程工具和方法纳入组织的标准软件过程。
4．描述软件科目间的内部过程界面。
软件工程科目的例子包括：
一软件需求分析，
一软件设计，
一编码，
一软件测试，
一软件配置管理，和
一软件质量保证。
5．描述在软件过程和其它受影响的组的过程之间的外部过程界面。


其它受影响的组的例子有：
一系统工程组，
一系统测试组，
一合同管理组，和
一文档支持组。
6．对负责组织软件过程活动的组（例如软件工程过程组）关于组织标准软件过程的更
改建议在更改被纳入标准过程之前建立文档、进行评审和批准。
造成更改的根源的例子有：
一软件过程评估的发现和建议，
一项目对组织标准软件过程的剪裁结果，
一从监控组织的和项目的软件过程活动中所得到的经验教训，
一组织的职员和经理所提议的更改，和
一被分析和解释的过程和产品的测量数据。
7．当合适时，制定将更改引入到现正进行的项目的软件过程中的计划。
8．在最初制定组织的标准软件过程时和每当对其作出重大更改或补充时，该标准软件
过程的描述经过同行评审。
参考同行评审关键过程区域。
9．将组织的标准软件过程的描述置于配置管理之下。
参考软件配置管理关键过程区域。
活动2
按照已制定的组织标准对组织的标准软件过程建立文档。
这些标准一般规定：
1．将过程分解为过程构成元素，这些元素具有为了了解和描述过程所需要的粒度。
每个过程元素包括一妥善定义的、有界的、紧密相关的活动集合。
过程元素的例子包括：
一软件估计元素，
一软件设计元素，
一编码元素，和
一同行评审元素。
过程元素的描述可以是待填充的样板，待完成的片段，待精炼的抽象，待修改或
已使用的未修改的完整描述。
2．描述每个过程元素并阐述：
?? 所要求的规程、条例（practice）、方法和技术；
?? 适用的过程和产品标准；
?? 实施过程的职责；
?? 所要求的工具和资源；
?? 输入；
?? 所生产的软件工作产品；
?? 应经受同行评审的软件工作产品；
?? 准备就绪和完成准则；和
?? 待来集的产品和过程数据。
3．描述过程元素间的关系，并阐述其：
?? 排序，
?? 界面，和
?? 内部相关性。
过程元素间的这种关系有时称作软件过程体系结构。
活动3
?? 对经批准供项目使用的软件生存周期的描述建立文档并进行维护。
软件生存周期的例子有：
一瀑布型，
一部分重叠的瀑布型，
一螺旋型，
一串型构造，和
一单个原型／部分重叠瀑布型。
1．软件生存周期与组织标准软件过程相容。
2．对于所提议的对软件生存周期描述的更改，在它们被采纳之前，由负责组织软件过
程活动的组（例如，软件工程过程组）建立文档、进行评审和批准。
3．软件生存周期的描述，在最初形成文档时和每当作重大更改和补充时，经受同行评
审。
参考同行评审关键过程区域。
4．对软件生存周期的描述进行管理和控制。
“进行管理和控制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知的
（即版本控制），而且以受控的方式引进更改（即更改控制）。
如果希望有比“进行管理和控制”所蕴含的更高程度的控制，则工作产品可置于配置管
理的完备的纪律之下，正如在软件配置管理关键过程区域中所描述的。
活动4
制定和维护项目剪裁组织标准软件过程的指南和准则。
1．剪裁指南和准则包括：
?? 选择和剪裁用于项目的软件生存周期，
?? 剪裁组织的标准软件过程以适应软件生存周期和项目的特征，和
?? 剪裁的例子包括：
一为新的生产线或宿主环境修改过程，
一为特定项目或项目类定制过程，和
一详细描述过程和在过程上增加细节使得所产生的项目定义软件过程能够通过。
?? 用于对项目定义软件过程建立文档的标准。
2．对剪裁的指南和准则所提议的更改，在它们被采纳之前，由负责组织软件过程活动


的组（例如软件工程过程组）建立文档、进行评审和批准。
3．对剪裁指南和准则进行管理和控制。
活动5
?? 建立和维护组织的软件过程数据库。
1．建立数据库去收集有关软件过程和产生的软件工作产品的数据，并使该数据适用。
过程和工作产品的数据的例子有：
一软件规模、工作量和成本的估计；
一有关软件规模、工作量和成本的实际数据；
一效率数据；
一质量度量；
一同行评审的范围（coverage）和效率；
一测试范围和效率；
一软件可靠性测量；
—在软件需求中发现的缺陷的数目和严重性；和
—在软件代码中发现的缺陷的数目和严重性。
2．评审进入数据库的数据以保证数据库内容的完整性。
此外，数据库也包含或索引那些实际的测量数据以及为了解和解释测量数据和评估其合
理性和适用性所需要的信息和数据。
3．管理和控制数据库。
4．控制用户存取数据库的内容以保证数据的完备性、完整性和精度。
存取仅限于需要进入、更改、评审、分析或抽取数据的人。
保护敏感数据并适当控制对这些数据的存取。
活动6
建立和维护软件过程一有关文档库。
软件过程一有关文档的例子包括：
一项目定义软件过程的描述，
一项目的标准，
一项目的规程，
一项目软件开发计划，
—项目测量计划，及
一项目的过程培训材料。
1．评审候选的文档产品，并将未来可能有用的适当产品放入库中。
2．对文档产品进行分类编目以便容易存取。
3．评审对当前库内的文档产品所作的修正，在合适时，更新库内容。
4．使得库内容可供软件项目和其它软件一有关组使用。
软件一有关组的例子有；
一软件质量保证组，
一软件配置管理组，
一软件测试组，和
一文档支持组。
5．定期评审每个文档产品的使用，将其结果用于维护库内容。
6．对库内容进行管理和控制。
测量和分析
测量1
进行测量并将测量结果用于确定组织的过程定义活动的状态。
测量的例子有：
一过程开发和维护的进度里程碑的状态，和
一过程定义活动的成本。
验证实施
验证1
软件质量保证组评审和（或）审计组织的开发和维护组织标准软件过程和有关过程财富
的活动和工作产品，并报告结果。
参考软件质运保证关键过程区域。
至少，这些评审和（或）审计要验证：
1．在开发、建立文档和维护组织标准软件过程和有关过程财富时遵循适当的标准。
2．控制和恰当地使用组织的标准软件过程和有关的过程财富。

证1 以便找到包括高级管理者监督评审的
典型内容的实践。
验证2
定期独立地评价培训大纲；看其与组织需要的一致性和贴切性。
验证3
评审和（或）审计培训大纲活动和工作产品，并报告其结果。
至少，评审和（或）审计要验证：
1．制定和修订组织培训计划的过程得到遵循。
2．制定和修订培训课程的过程得到贯彻。
3．培训记录得到适当地维护。
4．被指定为要求受某种特定培训的个人完成了那项培训。
5．组织的培训计划得到遵循。

证1 以便找到包括高级管理者监督评审的
典型内容的实践。
验证2
定期独立地评价培训大纲；看其与组织需要的一致性和贴切性。
验证3
评审和（或）审计培训大纲活动和工作产品，并报告其结果。
至少，评审和（或）审计要验证：
1．制定和修订组织培训计划的过程得到遵循。
2．制定和修订培训课程的过程得到贯彻。
3．培训记录得到适当地维护。
4．被指定为要求受某种特定培训的个人完成了那项培训。
5．组织的培训计划得到遵循。

软件的工程作业。
软件工程作业包括：分析分配给软件的系统需求（这些系统需求在需求管理关键过程区
域中加以描述）、制定软件需求、开发软件的体系结构、设计软件、用代码实现软件、集成
软件成分、和测试软件以验证它满足所规定的需求（即分配给软件的系统需求和软件需求）。
制定并评审为进行软件工程作业所必须的文档（即软件需求文档、软件设计文档、测试
计划和测试规程）以保证每个作业都针对其前面作业的结果，而它所产生的结果又适合于后
续的作业（包括运行软件和维护软件的作业）。当更改被批准时，受影响的软件工作产品、
计划、约定、过程和活动也要修改以反映该被批准的更改。
目标
目标1
定义和集成软件工程作业并一致地执行它们以生产软件。
目标2
软件工作产品彼此间保持一致。
执行约定
约定1
项目遵循书面的、有关进行软件工程活动的组织方针。
该方针一般规定：
1．按照项目定义软件过程进行软件工程作业。
参考集成软件管理关键过程区域的活动1 和2 以便找到包括项目定义软件过程的实践。
2．采用合适的方法和工具去构造和维护软件产品。
3．软件计划、作业和产品均可追踪到分配给软件的系统需求。
在这些实践中分配给软件的系统需求称为“分配需求”。
参考需求管理关键过程区域，以便找到包括分配给软件的系统需求的实践。
执行能力
能力1
为进行软件工程作业提供足够的资源和投资。
1．能完成以下各种软件工程作业的技术熟练的个人是可以得到的：
?? 软件需求分析，
?? 软件设计，
?? 编码，
?? 测试，和
?? 软件维护。
2．使得支持软件工程作业的工具合用。
一般支持工具的例子有：
一工作站，
一数据库管理系统，
一在线帮助工具，
一作图工具，
一交互式文档工具，和
一文字处理系统。
软件需求分析的支持工具的例子有：
一需求跟踪工具，
一规格说明工具，
一建立原型的工具，
一建模工具，和
一仿真工具。
软件设计的支持工具的例子有：
一规格说明工具，
一建立原型的工具，
一仿真工具，和
一程序设计语言。
编码的支持工具的例子有：
一编辑程序，
一编译程序，
一定义索引产生器，和
一巧妙的打印程序。
软件测试的支持工具的例子有；
一测试管理工具，
一测试生成程序，
一测试驱动程序，
一测试剖面，
—符号调试程序，和
一测试范围分析程序。
能力2
软件工程技术人员接受为完成他们的工作任务所要求的培训。
软件工程技术人员应接受应用领域方面的培训。
在软件需求分析方面培训的例子有：
—分析软件需求的原理；
一对任何持维护的现存软件，其现有的软件需求；
—为了制定软件需求而访问最终用户和应用领域专家所需的技巧（即需求的导出）；
—项目选择的、用于分析软件需求的工具、方法、惯例和标准的使用。
在软件设计方面培训的例子有：
一设计概念；
一对任何待维护的现存软件的现有设计；和
一项目选择的、用于设计软件的工具、方法、惯例和标准的使用。
在编码方面培训的例子有：
一所选择的编程语言；
一评审待维护的任何现存代码的现有源代码；
一项目选择的、用于编程的工具、方法、惯例和标准的使用；和
—单元测试技术。
在软件测试和其它验证技术方面培训的例子有：
一验证方法（分析、演示和审查，还有测试）；
—测试策划；
一项目选择的、用于测试和验证软件的工具、方法、惯例和标准的使用；
—测试准备就绪和完成的准则；和
一测试范围的测量。
参考培训大纲关键过程区域。
能力3
软件工程技术人员接受相关软件工程科目方面的定向培训。
相关软件工程科目的例子有：
一软件需求分析，
一软件设计，
一编码，
一测试，
一软件配置管理，和
一软件质量保证。
参考培训大纲关键过程区域。
能力4
项目经理和全部软件经理接受软件项目技术方面的定向培训。
定向培训的例子包括：
一软件工程的方法和工具，
一应用领域，
一可交付的和不交付的软件及相连的工作产品，和
一关于如何使用所选定的方法和工具管理项目的指南。
参考培训大纲关键过程区域

组间协调
等级3（已定义的）的一个关键过程区域
组间协调的目的是建立软件工程组与其它工程组一起积极参与的方式以使得项目更能
够有效地和效率高地满足顾客的需要。
组间协调包括软件工程组和其它项目工程组一起参与阐述系统层的需求、对象和问题。
项目工程组的代表，当合适时与顾客和最终用户一起工作，参与建立系统层的需求、对象和
计划，这些需求、对象和计划成为全部工程活动的基础。
对组间的技术工作界面和相互作用加以计划和管理以保证整个系统的质量和统一性。各
项目工程组的代表参与定期的技术评审和内部交流，以保证所有工程组都清楚各组的状态和
计划，并保证系统和组间的问题受到恰当的关注。
和这些工程作业有关的软件一专门实践在需求管理和软件产品工程关键过程区域中描
述。
目标
目标1
顾客需求得到全部受影响的组的认同。
目标2
工程组之间的约定得到受影响的组的认同。
目标3
工程组识别、跟踪和解决组间问题。
执行约定
约定1
项目遵循书面的组织上关于建立跨学科工程队伍的方针。
该方针一般规定：
1．全部受影响的组定义和评审关于项目的系统需求和项目层的目标。g
受影响的组的例子有：
一软件工程组，
一软件估计组，
一系统测试组，
一软件质量保证组，
一软件配置管理组，
一合同管理组，和
一文档支持组。
2．工程组协调其计划和活动。
3．经理负责建立和维护一个环境，它使得在项目工程组之间、当合适时在项目和顾客
或最终用户之间、以及贯穿整个组织的相互作用、协调、支持、和群组工作（teamwork）更
加方便。
在这些实践中所指的最终用户是顾客一指定的最终用户或最终用户的代表