执行能力
能力1
为和其它工程组～起协调软件工程活动提供足够的资源和投资。
能力2
不同工程组所用的支持工具是相容的，能够进行有效的通倍和协调。
应相容的支持工具的例子有；
一字处理系统，
一数据库系统，
一作图工具，
—电子表格程序，
一问题跟踪软件包，和
一库管理工具。
能力3
组织中的所有经理接受在以群组形式进行工作方面所要求的培训。
培训的例子有：
一建立群组；
一管理群组；
一建立、促进和便利群组工作；和
一组动态特性（groupdynamics）。
参着培训大纲关键过程区域。
能力4
在每个工程组中的全部作业领导在有关其它工程组所用的过程、方法和标准方面接受定
向培训。
参考培训大纲关键过程区域。
能力5
工程组的成员在作为一个群组进行工作方面接受定向培训。
参考培训大钢关键过程区域。
执行的活动
活动1
软件工程组和其它工程组，在合适时与顾客和最终用户一起参与建立系统需求。
具体说，这些组：
1．当合适时定义顾客和最终用户需求的关键特征。
2．商订关键的依赖关系。
3．当合适时，对每个将交付给顾客或最终用户的产品的验收准则建立文档。
活动2
项目软件工程组的代表和其它工程组的代表一起工作去监控和协调技术活动，以及解决
技术问题。
1．这些组的代表监控和协调技术活动通过：
?? 调整规格说明和提供对系统需求和系统设计的技术评审和批准；
系统需求和系统设计一般是系统工程组的职责，但是希望其它工程组的代表能有意义地
参与这些作业。
系统需求和系统设计包括：
一全面的系统需求，
一系统配置报(即硬件、软件和其它的系统成分），
一将需求分配到这些系统成分，并进行跟踪，和
一这些系统成分间界面的定义。
?? 提供在项目的整个生存周期内，为管理和控制系统需求和项目层目标的更改所
必须的项目层上的技术评审和分析；
?? 跟踪和评审关于硬件、软件和其它系统成分的设计和开发活动；和
?? 评估、制定对与多个工程组有关的技术风险的建议，并跟踪它。
参考集成软件管理关键过程区域的活动10 以便找到包含风险管理的实践。
2．组的代表处理技术问题，通过：
?? 解决项目层上的矛盾和澄清系统需求和设计问题；
?? 提出解决问题的联合建议；和
?? 阐述横跨项目多个工程组的过程问题。
活动3
将已文档化的计划用于交流组间约定，协调和跟踪所进行的工作
该计划：
1．是下列各项的基线：
?? 项目进度，
?? 项目的合同和技术方面，和
?? 对工程组的职责安排。
2．用于协调不同工程组之间的活动。
3．易于被所有工程组的成员使用。
4．被更新以便包括全部组间的约定和对这些约定的更改。
5．随着工作进展而更新以反映项目层上的进展和计划更改，特别当完成项目的里程碑
时和当计划有重大变化时。
6．由所有的工程组和项目经理评审和认同。
活动4
按照已文档化的规程识别、协调和跟踪工程组之间的关键依赖关系。
参考其成软件管理关键过程区域的活动9 以便找到包括管理关键依赖关系的实践。
这个规程一般规定：
1．明确地定义每个关键依赖关系，包括：
?? 拟提供的产品项，
?? 谁将提供它，
?? 何时提供它，和
?? 验收准则。
2．在软件工程组和项目及组织中的其它工程组之间协商关键依赖关系。
3．对关键依赖关系产品项的需要日期和可使用日期与项目进度和软件进度密切相关。
4．有关每个关键依赖关系的协议由接收组和负责提供关键依赖关系产品项的组双方共
同建立文档、评审和批准。
5．定期跟踪关键依赖关系，当合适时采取纠正措施。
?? 将状态和实际的或预测的完成情况与用来协调组间约定的计划相比较。
?? 评价迟后完成和过早完成的后果对将来的活动和里程碑的影响。
?? 向合适的经理报告实际的和潜在的问题。
活动5
所生产的作为其它工程组的输入的工作产品由接收组的代表评审以保证该产品满足他
们的需要。
活动6
对项目工程组的个别代表不能解决的组间问题按已文档化的规程加以处理。
组间问题的例子有：
一不相容的进度，
—不充分的投资，
一技术风险，
—系统层的设计和需求缺陷，和
一系统层问题。
活动7
项目工程组的代表进行定期的技术评审和交流。
在这些会议上，参加者：
1．当合适时，提供对顾客和最终用户的需求和希望的可视性。
2．监控项目的技术活动。
3．保证各组对技术需求的解释和实现符合系统需求。
4．评审约定以确定它们是否正被满足。
参考软件项目跟踪和监督关键过程区域以便找到包括评审的实践。
5．评审技术风险和其它的技术问题。
参考集成软件管理关键过程区域的活动10 以便找到风险管理的实践。

测量和分析
测量1
进行测量并将测量结果用于确定组间协调活动的状态。
测量的例子有：
一软件工程组为支持其它工程组所化资的实际工作量和其它资源；
一其它工程组为支持软件工程组所化费的实际工作量和其它资源；
一软件工程组为支持其它工程组的活动，对特定作业和里程碑的实际完成情况；和
一其它工程组为支持软件工程组的活动对特定作业和里程碑的实际完成情况。
验证实施
验证1
高级管理者定期参与评审组间协调的活动。
参考软件项目跟踪和监督关键过程区域的验证1 以便找到包括高级管理者监督评审的
典型内容的实践。
验证2
项目经理既定期地也事件驱动地参与评审组间协调的活动。
参考软件项目跟踪和监督关键过程区域的验证2 以便找到包括项目管理者监督评审的
实践。
验证3
软件质量保证组评审和（或）审计组间协调的活动和工作产品，并报告其结果。
参考软件质量保证关键过程区域。
这个关键过程区域的软件质量保证职责可以归入到一项复盖全部项目工程组的质量保
证的功能中。
至少，该评审和（或）审计要查证：
1．用于识别、协商和跟踪项目工程组之间的关键依赖关系的规程。
2．组间问题的处理。

目定义软件过程中加以标识，并作为软件项目策划
活动的一部分来安排进度，正如在集成软件管理中所描述的。
这个关键过程区域仅包括执行同行评审的实践。而识别需经受同行评审的具体软件工作
产品的实践则包含在描述每个软件工作产品的开发和维护的关键过程区域中。
目标
目标1
同行评审活动是有计划的。
目标2
识别和消除在软件工作产品中的缺陷。
执行约定
约定1
项目遵循书面的、组织上关于执行同行评审的方针。
该方针一般规定；
1．组织确定将经受同行评审的软件工作产品的一组标准。
2．每个项目确定将经受同行评审的软件工作产品。
参考集成软件管理关键过程区域的活动1 和组织过程定义关键过程区域的活动2 以便找
到包括识别要经受同行评审的软件产品的实践。
软件工作产品的例子包括：
一运行软件和支持软件，
一可交付的和不交付的软件工作产品，
一软件（例如源代码）和非软件工作产品（例如文档），和
一过程描述。
3．由经培训的同行评审领导者领导同行评审。
4．同行评审关注正被评审的软件工作产品，而不关注生产者。
5．管理者不使用同行评审的结果去评价个人的行为。
执行能力
能力1
对每个待评审的软件工作产品，提供足够用以执行同行评审的资源和投资。
提供资源和投资用以：
1．准备和散发同行评审的材料。
2．领导同行评审。
3．评审那些材料。
4．参加同行评审和根据同行评审识别出的缺陷所要求的任何后续评审。
5．监控根据同行评审识别出的缺陷对软件工作产品进行的返工。
6．收集和报告同行评审中所产生的数据。
能力2
同行评审领导者接受如何领导同行评审的培训。
培训的例子包括：
一同行评审的对象、原理和方法；
—策划和组织同行评审；
一评价同行评审的准备就绪准则和完成准则；
一执行和促进同行评审；
—报告同行评审的结果。
—跟踪和批准针对同行评审所确定的措施的那些返工；和
一收集和报告同行评审所要求的数据。
参考培训大纲关键过程区域。
能力3
参加同行评审的评审者接受在同行评审的对象、原理和方法方面所要求的培训。
培训的例子有：
一同行评审的类型（例如：软件需求评审、软件设计评审、编码评审和软件测试规程评
审）；
一同行评审的对象、原理和方法；
一评审者的任务；和
一估计用于准备和参加同行评审的工作量。
参考培训大纲关键过程区域。

执行的活动
活动1
计划同行评审，并将计划写成文档。
这些计划：
1.确定将经受同行评审的软件工作产品。
?? 所选定的软件工作产品包括在组织标准软件过程中所标识出的那组产品。
参考组织过程定义关键过程区域的活动2 以便找到包括组织的标准软件过程的实践。
2.规定同行评审的进度。
对于按进度在最近的将来要执行的同行评审，确定参加每一个同行评审的经培训的同行
评审领导者和其它的评审者。
活动2
按照已文档化的规程进行同行评审。
该规程一般规定：
1．由经培训的同行评审领导者计划和领导同行评审。
2．预先将评审材料散发给评审者以便他们能为同行评审作好充分的准备。
评审材料应包括要经受同行评审的软件工作产品的开发工作所需的有关输入。有关输入
的例子有：
一软件工作产品的对象，
一适用的标准，
一对设计模块的有关要求，或
一对代码模块的有关详细设计。
3．已对评审者分派了在同行评审中的任务。
4．详细说明和执行用于同行评审的准备就绪准则和完成准则。
?? 向合适的经理报告在满足这些准则方面的问题。
5．使用检查单，以便以一致的方式确定用于评审软件工作产品的准则。
?? 对于特定类型的工作产品和同行评审，需对检查单加以剪裁。
剪裁检查单所要考虑的问题的例子有：
一对标准和规程的符合性，
一完备性，
一正确性，
一构造的规则，和
一维护性。
?? 由检查单制定者的同行和潜在的用户评审检查单。
6．跟踪同行评审中所确定的措施直至它们得到解决。
7．同行评审的成功完成．包括解决同行评审中所识别出的问题的返工，被用作为相
关作业的完成准则。
活动3
记录有关同行评审的执行情况和结果的数据。
数据的例子包括；
—被评审的软件工作产品的标识，
一软件工作产品的规模，
一评审队伍的规模和组成，
一每个评审者的准备时间，
一评审会议的长度，
一发现和改正缺陷的类型和数目，和
一返工工作量。
测量和分析
测量1
进行测量并将测量结果用于确定同行评审活动的状态。
测量的例子包括：
一所完成的同行评审数与计划相比较，
一同行评审所化费的总的工作量与计划相比较，和
一被评审的工作产品数与计划相比较。
验证实施
验证1
软件质量保证组评审和（或）审计同行评审的活动和工作产品，并报告其结果。
参考软件质量保证关键过程区域。
至少，评审和（或）审计要验证：
1．所计划的同行评审已被执行。
2．同行评审的领导者得到适当的有关其角色的培训。
3．评审者得到在其角色方面的合适的培训或者对其角色是有经验的。
4．准备同行评审、执行同行评审和完成后继措施等的过程得到遵循。
5． 同行评审数据的报告是完全的、精确的和及时的。

等级4 关键实践

执行的活动
活动1
按照已文档化的规程制定软件项目的定量过程管理计划。
该规程一般规定；
l．定量过程管理计划基于：
?? 组织的有关产品质量、生产率和产品开发周期时间的战略目标；
?? 组织的测量大纲；
?? 组织的标准软件过程；
?? 项目的有关软件产品的质量、生产率和产品开发周期时间的目标；
?? 其它的项目定义软件过程的已测量的性能；和
?? 项目定义软件过程的描述。
2．该计划经受同行评审。
参看同行评审关键过程区域。
3．该计划由负责组织软件过程活动的组（例如软件工程过程组）评审。
4．对该计划进行管理和控制。
“进行管理和控制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知的
（即版本控制），而且以受控的方式引进更改（即更改控制）。
如果希望有比“进行管理和控制”所蕴含的更加正规的手续，则工作产品可置于配置管
理的完备的纪律之下，正如在软件配置管理关键过程区域中所描述的。
活动2
按照项目的定量过程管理计划执行软件项目的定量过程管理活动。
该计划包括：
1．定量过程管理活动的目标（goals ）和目的（objectives）。
2．将被测量的软件作业或其它的软件活动。
3．项目定义软件过程的测量装备（instrumentation）。
测量装备基于组织的测量大纲、组织标准软件过程的描述和项目定义软件过程的描述。
4．将执行的定量过程管理活动和关于这些活动的时间表。
除了当前组织和项目的需要之外还应包括对将来的工作可能有用的测量。
5．负责定量过程管理活动的组和个人。
已执行定量过程管理活动所需要的资源，包括人员和工具。
7.在执行定量过程管理活动中应遵循的规程。
活动3
在项目定义软件过程的基础上，确定数据采集的策略和应作的定量分析。所考虑的项目
定义软件过程的属性包括：
1．作业、活动和它们彼此间的关系。
2．软件工作产品和它们彼此间的及它们对项目定义软件过程的关系。
3．过程控制点和数据采集点。
活动4
按照已文档化的规程，采集用于定量地控制项目定义软件过程的测量数据。
该规格一般规定：
1．所采集的测量数据支持组织的和软件项目的测量目标和目的。
2．要确定应采集的具体测量数据、它们的精确定义、对每项测量所预想的使用和分析、
以及这些测量数据的过程控制点。
测量数据的例子包括：
一在软件规模、成本和进度方面，估计的／计划的数据与实际数据相比较；
一生产率数据；
一正如在软件质量计划中所定义的质量度量；
一同行评审的范围和效率；
一培训的有效性；
一测试的范围和效率；
一软件可靠性度量；
一在软件需求中所发现的缺陷的数目及严重性；
一在软件代码中所发现的缺陷的数目及严重性；
一措施条款中已结束条款的数目和比例。
3．从整个软件生存周期（例如，既有开发阶段又有后开发阶段）选择测量。
4．测量包括关键软件过程活动和主要软件工作产品的特性。
5．在遍及所有软件项目上一致地收集有关组织标准软件过程的测量数据。
6．要控制的度量都是软件活动的自然的结果（在可能处）。
7．选择支持预先确定的分析活动的测量。
在某些情况，测量可以是面向研究的但应明确指明这点。
8．独立地评估测量数据的有攻连。
9．当合适时，将所采集到的测量数据存储到组织的软件过程数据库中。
参阅组织过程定义关键过程区域的活动5 以便找到包括组织软件过程数据库的实践。
活动5
按照已文档化的规程分析项目定义软件过程，并将其置于定量控制之下。
该规程一般规定：
1．预先确定具体的数据分析活动。


数据分析活动的描述包括：
一所要求的输入数据，
一使用的工具，
一所进行的数据操作，
一要导出的信息，和
一在进行分析时所用的决策判据和作为分析结果所决定的将要采取的措施。
分析技术的例子包括：
一Pareto 图（Paretodiagrams），
一控制图（contrdcharts），
一趋向图（trenddiagrams）和
一散布图（scatterdiasrams）
2．识别、采集和分析贯穿整个项目定义软件过程的过程活动的测量数据。
3．所选出的测量恰当地描述它们所表示的过程的特征。
4．对每个度量确定其预计的均值和方差值。
5．确定每个度量的可接受范围，并建立项目的过程性能基线。
建立可接受的范围的一个例子是从过程的平均性能计算过去的偏差。
6．将每个度量的实际值与预计的均值和方差值相比较。
实际过程性能与已确定的可接受范围相比较的例子有：
一将在每千行源代码上所化费的同行评审小时数与通过分析过去数据所确定的上
限和下限作比较；和
一将由软件需求（例如“必须”实现的功能数(“shalls”数)）换到源代码行数
的扩展率与通过分析过去的数据所确定的上限和下限作比较。
7．当合适时作出调整以使得实际过程性能与已确定的可接受范围相一致。
8.当项目定义软件过程受到定量控制时，建立以下各项的基线：
?? 测量的定义，
?? 实际测量数据，和
?? 度量的可接受范围。
9．管理和控制软件项目的过程性能基线。
活动6
准备和散发对软件项目的定量过程管理活动结果的书面报告。
1．在将数据分析结果报告给任何其它人之前，和受该数据影响的那些人一起评审该数
据分析结果。
2．软件经理、软件作业领导和高级管理者收到常规的适合其需要的报告。
3．软件质量保证组收到常规的适合其需要的报告。
4．项目经理、高级经理、软件经理和软件作业领导收到应其请求的专门报告。
活动7
按照已档化的规程建立和维护组织标准软件过程的过程能力基线。
该规程一般规定；
1．在组织的软件过程数据库中记录项目的软件过程数据，正如在过程性能基线中所概
括的那样。
参看组织过程定义关键过程区域的活动5 以便找到包括组织软件过程数据库的实践。
2．当合适时，将每个项目定义软件过程的过程性能基线纳入到组织标准软件过程的过
程能力基线中。
3．将组织标准软件过程的过程能力基线写成文档。
4．考查组织标准软件过操的过程能力趋势以预测最可能的问题或改进的机会。
使用能力趋势的例子有：
一预计软件缺陷的发生并将预计的和实际的相比较，和
一基于来自同行评审和（或）测试的数据预计产品中残留缺陷的分布和特征。
多半是缺陷源的区域的例子有：
一用于估计和策划的条款，
一在软件生存周期的早期（例如需求分析）所进行的活动，
一主要的文档条款，
一在过去一直是易于引入缺陷的条款和活动，
一实施更改和修正缺陷的活动，和
一人工密集的活动。
多半是改进机会的区域的例子有：
一其它项目和组织已经成功地自动化的活动，
一不交付的和支持性的产品项（item）和活动，例如培训和工具，
一面向质量的活动，例如同行评审和测试，及
一人工密集的活动。
5．对组织标准软件过程的过程能力基线进行管理和控制。
6．当承担的软件项目与过去的项目有本质不同时，作为剪裁组织标准软件过程的一部
分建立那个项目的新的过程性能基线。
参看集成软件管理关键过程区域的活动1 以便找到包括项目剪裁组织标准软件过程的
实践。
本质不同的例子有：
一新的应用领域，
一采用根本不同的技术，和183
一在应用规范上的显著变化。
7．跟踪和分析对组织标准软件过程的更改以便评估其对过程能力基线的影响。

结果用以确定定量过程管理活动的状态。
测量的例子包括：
—一段时间内定量过程管理的成本与计划作比较的结果；
一定量过程管理活动的进度里程碑的完成情况，用与已批准的计划（例如确立对有
关项目将采用的过程测量、确定将如何收集过程数据，以及采集过程数据）作比
较的结果来表示。
验证实施
验证1
高级管理者定期参加评审定量过程管理活动。
参看组织过程焦点关键过程区域的验证1 和软件项目跟踪和监督关键过程区域的验证l
以便找到包括高级管理者监督评审的典型内容的实践。
验证2 项目经理既定期地也事件驱动地参与评审软件项目的定量过程管理的活动。
参看软件项目跟踪与监督关键过程区域的验证2 以便找到包括项目管理者监督评审的
典型内容的实践。
验证3
软件质量保证组评审和（或）审计定量过程管理的活动和工作产品，并报告其结果。
参看软件质量保证关键过程区域。
至少，评审和（或）审计要验证：
1．定量过程管理活动的计划得到遵循。
2．定量过程管理的规程得到遵循。
3．正如所要求的那样进行定量过程管理数据的采集和分析工作，包括验证：
?? 存在所需要的数据，
?? 已收集所需要的数据，
?? 所收集的数据是需要的，
?? 所收集的数据支持组织测量大纲的目标和目的，
?? 通过数据的有用性对收集数据成本的合理性作出解释，
?? 在软件生存周期的恰当点上收集数据，
?? 数据是精确的且正确的，
?? 数据是及时的，和
?? 数据的保密性受到恰当的保护。

软件子合同管理
等级2（可重复的）的一个关键过程区域
软件于合同管理的目的是选择合格的软件子承包商并有效地管理他们。
软件于合同管理包括选择软件予承包商、建立和子承包商的约定，及跟踪和评审子承包
商的性能和结果。这些实践包括对纯软件子合同的管理，也包括对子合同的软件成分的管理，
后者含有软件、硬件和可能有的其它系统成分。
基于子承包商完成工作的能力选择子承包商。许多因素对将主承包商工作的一部分签为
子合同的决策产生影响。选择子承包商可以基于战略经营同盟及技术上的考虑。这个关键过
程区域的实践阐述与将工作的一个确定部分签子合同给另一个组织相联系的传统的采购过
程。
当签子合同时，建立一个包括技术和非技术（例如交付日期）需求的已文档化的协议并
将其用作管理于合同的基础。对将由于承包商完成的工作和关于该工作的计划建立文档。子
承包商将遵循的标准和主承包商的标准一致。
子承包商的软件的策划、跟踪和监督活动由于承包商完成。主承包商确保恰当地完成这
些策划、跟踪和监督活动并且确保子承包商交付的软件产品满足其验收准则。主承包商和子
承包商一起工作去管理他们的产品和过程界面。
目标
目标1
主承包商选择合格的软件予承包商。
目标2
主承包商和软件子承包商认同他们相互的约定。
目标3
主承包商和软件子承包商保持不断的通信。
目标4
主承包商对照约定跟踪软件予承包商的实际结果和性能。
执行约定
约定1
项目遵循书面的管理软件予合同的组织上的方针。
该方针一般规定；
1、在选择软件予承包商和管理软件子合同时采用已文档化的标准和规程。
2、合同协议形成管理干合同的基础。
3、对子合同的更改需由主承包商和子承包商共同介入和认同。
约定2
指派一个子合同经理负责建立和管理软件子合同。
1、子合同经理本人在软件工程方面是博学的和有经验的，或者他已配备有具有这方面
知识和经验的个人。
2、子合同经理和受影响的当事人一起负责协调待签子合同工作的技术范围及子合同的
条件和条款。
项目的系统工程组和软件工程组确定待签子合同工作的技术范围。适当的经营功能组一
例如采购、财务和法律组，建立和监控于合同的条款和条件。
3、子合同经理负责：
?? 选择软件予承包商，
?? 管理软件予合同，和
?? 安排子合同产品的后一子合同支持。
执行能力
能力1
?? 为选择软件予承包商和管理于合同提供足够的资源和投资。
1、确定软件经理和其它个人管理子合同的具体职责。
2、使得支持管理子合同的工具可用。
支持工具的例子包括：
一估计模型，
一电子表格程序，和
一项目管理和编制进度程序。
能力2
参与建立及管理软件予合同的软件经理和其它个人受到完成这些活动的培训。
培训的例子的有：
一准备和策划软件予合同的签订，
一评价子合同投标者的软件过程能力，
一评价子合同投标者的软件估计和计划，
一选择子承包商，和
一管理子合同。
能力3
参与管理软件子合同的软件经理和其它个人在子合同的技术方面接受定向培训。
走向培训的例子有：
一应用领域，
一正运用的软件技术，
一正使用的软件工具，
一正使用的方法论，
一正使用的标准，和
一正使用的规程。
执行的活动
活动1
按照已文档化的规程定义和规划待签子合同的工作。
该规程一般规定：
1、基于对项目的技术特征和非技术特征所作的综合评估，选择待签子合同的软件产品
和活动。
?? 选择待签子合同的功能或子系统，使其与潜在于承包商的技能和能力相匹配。


?? 基于对系统和软件需求所作的系统性分析和恰当的划分，确定对待签子合同的
软件产品和活动的规格说明。
2、从项目的以下各项导出对待签子合同工作的规格说明和将遵循的标准和规程：
?? 工作陈述，
?? 分配给软件的系统需求，
?? 软件需求，
?? 软件开发计划，和
?? 软件标准和现程。
3、对子合同的工作陈述进行：
?? 准备，
?? 评审，
?? 认同，
评审和认同子合同工作陈述的个人的例子包括：
一项目经理，
一项目软件经理，
一应负责的软件经理，
一软件配置管理经理，
一软件质量保证经理，和
一子合同经理
?? 当需要时修订，和
?? 管理和控制。
“进行管理和控制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知的
（即版本控制），而且以受控的方式引进更改（即更改控制）。
如果希望有比“进行管理和控制”所蕴含的更高程度的控制，则工作产品可置于配置管
理的完备的纪律之下，正如在软件配置管理关键过程区域中所描述的。
参考软件项目织划关键过程区域的能力1 以便找到包括工作陈述的典型内容的实践。
4、在准备子合同的工作陈述的同时准备一份选择子承包商的计划，合适时要进行评审。
活动2
按照已文档化的规程，在评价子合同投标者完成该工作的能力的基础上选择软件子承包
商。
这个规程包括对以下各项的评价：
1、所提交的对计划中的子合同的建议。
2、以前在类似工作方面的性能记录，如果有的话。
3、子合同投标者的组织相对于主承包商的地理位置。
对某些子合同的有效管理可能要求频繁的面对面的相互交流。
4、软件工程和软件管理能力。
评价子承包商能力的方法的一个例子是SEI 软件能力评价方法。
5、为完成该工作可得到职员。
6、以前在类似应用领域的经验，包括子承包商的软件管理队伍所具有的软件专门知识。
7、可用资源。
资源的例子包括
一设施，
一硬件，
一软件，和
一培训。
活动3
将主承包商和软件子承包商间的合同协议用作管理子合同的基础。
该合同协议用文档记载以下各项：
1、条款和条件。
2、工作陈述。
参考软件项目策划关键过程区域的能力1 以便找到包括工作陈述的典型内容的实践。
3、对待开发产品的需求。
4、子承包商和主承包商之间的依赖关系表。
5、将交付给主承包商的子合同产品。
产品的例子有：
一源代码，
一软件开发计划，
一仿真环境，
一设计文档，和
一验收测试计划。
6、提交产品修订的条件。
7、在主承包商接收子合同产品之前评价子合同产品时将用的验收规程和验收准则。
8、主承包商用来监控和评价子承包商性能的规程和评价准则。
活动4
主承包商评审和批准已文档化的子承包商软件开发计划。
1、这个软件开发计划包括（直接地或通过引证）主承包商软件开发计划中的适当条款。
在某些情况下，主承包商的软件开发计划可能包括于承包商的软件开发计划，因此无需
单独的子承包商软件开发计划。
参考软件项目策划关键过程区域的活动7 以便找到包括项目软件开发计划的内容的实
践。
活动5
将已文档化的且经批准的子承包商软件开发计划用于跟踪软件活动和通信状态。
活动6
按照已文档化的规程判定对软件予承包商的工作陈述、子合同条款和条件、以及其它约
定的更改。
1、该规程一般规定，主承包商和子承包商的所有受影响的组都要参与。
活动7
主承包商的管理者和软件子承包商的管理者一起执行定期的状态或协调评审.
1、当合适时，向子承包商提供对产品顾客及最终用户的需要及希望的可视性。


---------------------------
软件能力成熟度模型(cmm1.1)(计算机化组件监控).pdf - Adobe Reader: AcroRd32.exe - 应用程序错误
---------------------------
"0x01301b7e" 指令引用的 "0xbabeaabe" 内存。该内存不能为 "read"。
要终止程序，请单击“确定”。
要调试程序，请单击“取消”。
---------------------------
确定   取消   
---------------------------

缺陷预防
等级5（优化的）的一个关键过程区域
缺陷预防的目的是鉴别缺陷的原因并防止它们再出现。
缺陷预防包括分析过去曾遇到的缺陷和采取特别措施以防止将来再出现此类缺陷。缺陷
可能曾在其它项目中和在当前项目的早期阶段或作业中已经鉴别出来。缺陷预防活动也是在
项目间传播经验教训的一种机制。
为了跟踪已遇到过的缺陷类型和识别出多半会再出现的缺陷，必须对趋势进行分析。基
于对项目定义软件过程和其实施方式（正如在集成软件管理和软件产品工程关键过程区域中
所描述的）的理解，确定缺陷的根本原因和对于未来活动缺陷的推断。
项目和组织均采取预防缺陷再出现的特别措施。某些组织的措施可以像在过程更政管理
关键过程区域中所描述的那样处理。
目标
目标1
缺陷预防活动是有计划的。
目标2
缺陷的一般原因已经找出和标识。
目标3
缺陷的一般原因已按优先级排序和系统地消除。
执行约定
约定1
组织遵循书面的用于缺陷预防活动的方针。
该方针一般规定：
1．制定有关缺陷预防的投资、人员配置和其它资源的长期计划和约定。
2．安排缺陷预防活动所需要的资源。
3．在全组织范围内实施缺陷预防活动以改进软件过程和产品。
4．评审缺陷预防活动的结果以保证这些活动的有效性。
5．阐述那些作为缺陷预防活动的结果所鉴别出的管理和技术方面的措施。
约定2
项目遵循书面的关于缺陷预防活动的组织上的方针。
该方针一般规定：
1．在每个项目的软件开发计划中包括缺陷预防活动。
2．安排缺陷预防活动所需要的资源。
3．阐述那些作为缺陷预防活动的结果所鉴别出的项目管理和技术方面的措施。

负责组织软件过程活动的组（例如，软件工程过程组）的一部分，或
者其活动与后者紧密地配合。
参看组织过程焦点关键过程区域。
能力2
存在协调软件项目的缺陷预防活动的群组。
1．这个群组与负责开发和维护项目定义软件过程的群组紧密结合。
协调缺陷预防活动的群组的成员通常是非全日制的，他们有其它的软件工程活动作为其
主要的职责。
参看集成软件管理关键过程区域的活动1 和2 以便找到包括开发和维护项目定义软件过
程的实践。
能力3
在项目层和组织层都要为缺陷预防活动提供足够的资源和投资。
1．当合适时，将缺陷预防活动设计为每个人的职责。
缺陷预防活动的例子包括：
一作业起动会议，
一原因分析会议，
一评审和策划所提议的措施，和
一实施措施。
2．制定了管理者参与缺陷预防活动的计划。
3．当合适时，每个软件项目均派有代表参加协调组织的缺陷预防活动的群组。
4．使得支持缺陷预防活动的工具适用。
支持工具的例子包括：
一统计分析工具，和
一数据库系统。
能力4
软件工程组和其它软件一有关组的成员接受执行其缺陷预防活动所要求的培训。
软件一有关组的例子包括：
一软件质量保证组，
一软件配置管理组，和
一文档支持组。
培训的例子包括：
一缺陷预防方法，
一作业起动会议的开法，
一原因分析会议的开法，和
一统计方法（例如因／果图和Pareto 分析）。
参着培训大纲关键过程区域。
执行的活动
活动1
软件项目制定和维护一个有失其缺陷预防活动的计划。
该计划：
1．确定将开展的缺陷预防活动（例如作业起动会议和原因分析会议）。
2．规定缺陷预防活动的日程表。
3．包括所指派的职责和所要求的资源——包括人员和工具。
4．经历同行评审。
参阅同行评审关键过程区域。
活动2 在一个软件作业开始时，承担此作业的群组的成员聚在一起准备该作业的活动和
有关的缺陷预防活动。
举行起动会议，使该组成员熟悉过程实施的细节，以及对过程的任何最新更改。
这些起动会议的内容包括；
1．适用于该作业的软件过程、标准、规模、方法和工具，重点放在最近的更改上。
作为评价以前原因分析舍议所作出建议的一项实验，可能进行更改。
2．该作业所要求的且可得到的输入。
3．要产生的输出，如果可能用例子说明。
4．拟用来评价输出的方法。
5．拟用来验证对软件过程的遵守情况的方法。
6．在当前阶段通常会作出的或引入的差错的清单，以及推荐的预防这些差错的措施。
7．群组的任命。
8．作业日程表。
9．作业和软件项目的软件产品质量目标。
参看软件质量管理关键过程区域。
活动3
按照已文档化的规程进行原因分析会议．
该规程一般规定：
1．每个执行软件作业的群组均召开原因分析会议。
?? 在作业完成后紧接着召开原因分析会议。
?? 在软件作业期间当已发现的缺陷的数目表明需要附加的会议时，也召开会议。
?? 在软件产品交付给顾客后，当合适时召开定期的原因分析会议。
?? 对于长软件作业，当合适时，召开定期的过程中缺陷预防会议。
长作业的一个例子是依赖于努力等级的（alevel-of-effort）、顾客支持作业。
2．由在举办原因分析会议方面经过培训的人领导此会议。
3．鉴别和分析缺陷以确定其根本原因。
确定根本原因的方法的一个例子是因果图。
4．将缺陷归入根本原因的各个类别中。
缺陷根本原因的类别的例子有：
一不恰当的培训，
一通信中断，
一没有说明问题的全部细节，和
一在人工手续（例如，打印）中出错。


5．制定为预防将来出现已识别出的缺陷和类似的缺陷而建议的措施并写成文档。
建议的措施的例子包括对以下各项的修改：
一过程，
一培训
一工具，
一方法，
一通信，和
一软件工作产品。
6．对缺陷的一般原因加以识别并写成文档。
一般原因的例子包括：
一在引用某个系统功能时出现的频发的差错，和
一在软件单元的某个相关组中出现的频发的差错。
7．将会议结果记录在案，供组织和其它项目用。
活动4
受指派协调缺陷预防活动的每个群组定期相聚，评审和协调得自原因分析会议的措施建
议的实施情况。
所涉及的群组可以是在组织层上的，也可以是在项目层上的。
这些群组：
1．评审原因分析会议的结果和选择将采纳的措施建议。
2．评审组织中其它协调缺陷预防活动的群组已经分派给它们的措施建议，并挑选出将
采纳的措施建议。
3．评审组织中其它群组所采取的措施以便评估这些措施是否适用于它们的活动和过程。
4．对措施建议进行初步分析并设置其优先级。
优先级一般是不严格的，基于对以下各项的理解：
一缺陷的原因，
一不解决这些缺陷所蕴含的问题，
一实施旨在预防这些缺陷的过程改进的成本，和
一预期的对软件质量的影响。
用于设置措施建议的优先组的技术的～个例子是Pareto 分析。
5．当合适时在组织的另一个层次上再给群组重新安排措施建议。
6．将决策的理论根据记入文档，并将决策和其根据提供给措施建议的提议者。
7．为实施措施建议的行动条款分配职责。
?? 行动条款的实施包括对本群组的权限范围内的活动作出立即的更改和为其它的更
改作安排。
?? 通常群组的成员实施行动条款，但在某些情况下，群组也能安排其它人去实施一项
行动条款。
8．评审缺陷预防实验的结果，并当合适时，采取措施将成功实验的结果纳入项目或组
织的其余部分。
缺陷预防实验的例子有：
—使用一个暂时的经修改的过程，和
一使用一个新工具。
9．跟踪措施建议和行动条款的状态。
10．当合适时，对组织标准软件过程和项目定义软件过程的软件过程改进建议建立文档。
指定措施建议的提议者作为软件过程改进建议的提议者。
参阅过程更政管理关键过程区域的活动5 以便找到包括处理软件过程改进建议的实践。
11．在行动条款结束之前，评审和验证已完成的行动条款。
12．保证那些在预防缺陷上的重要工作和成功得到公认。
活动5
在所有群组协调缺陷预防的活动中均将缺陷预防数掘记入文档并对其进行跟踪。
1．将在原因分析会上确定的措施建议写成文档。
在措施建议的描述中包含的数据的例子有：
一措施建议的发起者，
一缺陷的描述，
一缺陷原因的描述，
一缺陷原因的类别，
一缺陷引入的阶段，
一缺陷被识别出的阶段，
一措施建议的描述，和
一措施建议的类别。
2．将措施建议中建议的行动条款写入文档。
行动条款的描述中包含的数据的例子有：
一负责实施的人，
—对受它影响的区域的描述，
一不断收到有关它状态报告的个人，
一其状态的下一次评审日期，
一关键决策的依据，
一实施行动的描述，
一识别缺陷和改正它所化费的时间和成本，和
一不修复此缺陷带来的损失。
3．对缺陷预防数据进行管理和控制。
“进行管理和控制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知的
（即版本控制），而且以受控的方式引进更改（即更改控制）。
如果希望有比“进行管理和控制”所蕴含的更高程度的控制，则工作产品可置于配置管
理的完备的纪律之下，正如在软件配置管理关键过程区域中所描述的。
活动6
按照已文档化的规程采纳由缺陷预防措施所导致的对组织标准软件过程的修改。
参着组织过程定义关键过程区域的活动1 以便找到包括组织标准软件过程的实践。
活动7
按照已文档化的规程采纳由缺陷预防措施所导致的对项目定义软件过程的修改。
参看集成软件管理关键过程区域的活动2 以便找到包括项目定义软件过程的实践。
活动8
软件工程组和软件一有关组的成员定期收到有关组织的和项目的缺陷预防活动的状态
和结果的反馈信息。
该反馈提供：
1．主要缺陷类别的摘要。
2．缺陷在主要缺陷类别中的频率分布。
3．为处理主要缺陷类别所采取的重大的创新和措施。
4．措施建议和行动条款的概括的状态。
提供这项反馈的方法的例子有：
一电子布告栏，
一业务通信，
一信息流会议（informat。onflowmeetings ）。

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