看到哪里发到哪里,果然用电脑看电子书很慢

敲头,你才是懒惰呢,
今天有没有看书,如果不好好学习,我以后就抓只蟑螂放你衣服里

4.4.3 组织机构的独立性问题
为使那些要求独立性的关键实践得到恰当的解释和遵循，组织必须十分小心。特别对小
的项目都小的组织更是如此。当技术上或机构上的偏差可能影响有关项目的质量或风险时，
关键实践要求独立性。例如，两个涉及独立性的实践是；
?? SQA 组有～个独立于项目经理、项目软件工程组和其它软件一有关组的向高级管
理者报告的渠道（软件质量保证中的约定1．2）。
?? (统和验证）测试用例和测试规程由独立于软件开发者的测试组进行规划和准备（软
件产品工程中活动7．3）。
需要系统测试和验证测试的独立性是基于技术上的考虑。该独立性保证测试者不会受到
软件开发者或维护者所作的设计决策和实施决策的不恰当的影响。
软件质量保证组的独立性是必须的，这样才能使其成员的工作能不受进度和成本压力的
影响。没有机构上的独立性要保证有效的操作上的独立性是困难的。例如，即使存在严重的
不符合问题，一个要向项目经理报告的雇员也可能不愿意停止测试活动。
组织必须确定这样的组织机构，它将在组织的战略经营目标和经营环境的上下文中支持
要求独立性的活动，例如SQA。
独立性应该：
?? 给执行SQA 任务的个人提供组织上的自由度，使其能成为高级管理者了解项目的
“耳目”。
?? 执行SQA 任务的个人，使其免受被监督项目管理者所作的性能评价的影响，
?? 使高级管理者相信正在报告的有关项目过程和产品的信息是客观的。
由于关键实践允许对独立性准则作解释，在确定关键过程区域的目标是否已达到时组织
必须运用专业判断。

4.5 运用专业判断
使得所提供的一组完整的正确的原则能运用到广泛的情况，对某些关键实践有意阐述得
允许有灵活性。在关键实践中广泛采用了不确定的短语如“受影响的组”、“当合适时”和“当
需要时”。在关键实践中通常已经努力做到最少使用这种不确定的术语，而且在许多情况下
提供了例子，至少在策一次使用该术语时是如此。但是，对于两个不同的组织，对于同一组上，这些短语可能有不同的含义。因
此，每个项目或组织必须就其具体情况澄清这些短语。
澄清这些短语要求组织考虑使用它们时的整体的上下文。一个贴切的提问是对这样一个
短语的具体解释是否满足该关键过程区域的目标。在确定目标是否已满足时必须采用专业判
断。附录B 中的术语汇编在解释关键实践中的这些短语或其它短语时能提供指导。
当解释关键实践和它们如何对关键过程区域的目标作贡献时也必须使用专业判断。一般
讲，关键过程区域描述所有软件组织均应该具有的～组基本的行大，而不管他们的规模或他
们的产品如何。可是必须根据项目的或组织的经营环境或具体情况解释CMM 中的关键实
践。
这种解释应该既基于对CMM的深刻了解，也基于对组织和其项目的丰富知识。关键过
程区域的目标提供了构造这个解释的一个方法。如果一个组织关键过程区域的实施方法能满
足该区域的目标，但它们明显地不同于一般意义下的关键实践，那么解释的理论基础必须用
文档记载。已文档化的理论基础将帮助评估或评价组理解为什么某些实践以他们现在的方式
实施。
运用专业判断导致软件过程的“化度｛goodnes。）”问题。尽管在许多软件环境中CMM
确实建立了用于判断一个“合理”过程的最低限度的准则，但它并不对软件过程提出“优度”
要求。过程管理的目的是建立能使用的过程，并且该过程能作为基于组织的经营需求进行系
统改进的基础。
用于判断一个“合理”软件过程的准则是什么呢？一个合理的软件过程是这样的过程，
它在建立组织的能力方面是有效的，并且满足已定义过程的大多数要求。具体地讲，它是实
用的、已文档化的、已实施的、经培训的、已测量的和能改进的。
如果一个组织建立一个用于估计的软件过程，而该估计由掷骰子组成，那么它是一个合
理的过程吗？可以肯定它能文档化并得到一致遵循。某些人甚至说它和许多其它估计技术一
样实际。可是大多数软件专业人员不会认为“掷骰子”是一个合理的估计过程。因为它仅仅
遵从概率定律，它不可能被改进。
“掷骰子”和另一个过程“去问乔治”之间差别有多大？后者可能是一个非常好的估计
方法。只要乔治在周围，估计甚至是一致的和可重复的。可是它也不能满足我们的准则，因
为其它的个人不可能受到此方法的培训。这正是一个以人为中心的过程，没有乔治过程就不
可能重复。它不能建立一种前进的组织能力。
通常认为采用Delphi 方法（此方法是有关某专题的专家评审考虑中的议题，并且就有
关此议题的建议形成一致意见）的某种变形去作估计是合理的软件过程。基于DelPhi 方法
的规模估计方法满足用以判断一个合理、有效过程的准则，尽管Delnhi 方法也是一个以人
为中心的过程。组织的能力可以建立在诸如Detohi 方法等结构化技术之上。
在根本意义上说，为了作出这样的区分，专业判断是必须的。困难在于分辨出符合性和
优度。目标概括关键实践，而关键实践又描述合理的软件过程。可是符合一个合理过程并不
意味着该过程在实现其目的上是有效的。可能有许多因素影响组织和项目的成功。例如某些
成功的项目生产出的产品无人购买，这在商界是个失败。
“优度”属性只能在经营环境和具体的项目和组织情况下加以解释。只有组织能作出这
样的“优度”判断，这种判断是组织连续过程改进周期的一部分。因为永远不会实现完美元
缺，因此连续过程改进决不会终止。

需求管理
等级2（可重复的）的一个关键过程区域

需求管理的目的是在顾客和将处理顾客需求的软件项目之间建立对顾客需求的共同理
解。
需求管理包括和顾客一起建立和维护有关软件项目需求的协议，该协议称作“分配给软
件的系统需求”。“顾客”可解释为系统工程组、销售组、另一个内部组织、或者一个外部顾
客。协议既包括技术需求、又包括非技术需求（例如交付日期）。该协议形成估计、策划和
跟踪整个软件生存周期内软件项目活动的基础。
将系统需求分配给软件、硬件和其它系统成分的工作可能由软件工程组之外的组测如系
统工程组）完成，软件工程组可能对此分配无直接控制。在项目约束范围内，软件工程组采
取恰当步骤以保证对分配给软件的需求建档、并加以控制，该组负责处理分配给软件的系统
需求。
为实现此控制，软件工程组评审初始的和经修改的分配给软件的系统需求，以便在它们
被纳入软件项目之前使问题得以解决。每当改变分配给软件的系统需求时，都要调整受
到影响的软件计划，工作产品和活动，使其与更新后的需求保持一致。

目标
目标1 分配给软件的系统需求是受控的，建立供软件工程和管理使用的基线。
目标2 软件计划、产品和活动与分配给软件的系统需求保持一致。

软件项目策划
等级2（可重复的）的一个关键过程区域
软件项目策划的目的是为完成软件工程和管理软件项目制定合理的计划。
软件项目策划包含估计待完成的工作，建立必要的约定和确定进行该工作的计划。
软件策划首先作出有关待完成的工作和其它定义及界定软件项目的约束和目标（由宪来
管理关键过程区域的实践所建立的）的陈述。软件策划过程包括以下步骤：估计软件工作产
品规模及所需的资源，制定时间表，鉴别和评估软件风险和协商约定。为了制定软件计划（即
软件开发计划），可能需要重复地通过这些步骤。
该计划提供完成和管理软件项目活动的基础，并按照软件项目的资源、约束和能力，阐
述对软件项目的顾客作的约定。
目标
目标1
对供策划和跟踪软件项目用的软件估计已建立文档。
目标2
软件项目的活动和约定是有计划的并已建立文档。
目标3
受影响的组和个人同意他们的关于软件项目的约定。
执行约定
约定1 指定项目软件经理负责协商约定和制定项目软件开发计划。
约定2 项目遵循书面的组织的用于策划软件项目的方针。
该方针一般规定：
1、配给软件的需求用作为策划软件项目的基础。
参考需求管理关键过程区域的活动2。
2、下列人员之间协商软件项目的约定：
?? 项目经理，
?? 项目软件经理，和
?? 其它的软件经理。
3、其它的工程组协商他们介入该软件活动的事宜，并记入文档。
其它工程组的例子包括：
一系统工程组，
一硬件工程组，和
一系统测试组。
4、影响的组评审软件项目的；
?? 软件规模估计，
?? 工作量和成本估计，
?? 进度，和
?? 其它约定。
受影响的组的例子有；
一软件工程组（包括所有的小组，例如软件设计小组），
一软件估计组，
一系统工程组，
一系统测试组，
一软件质量保证组，
一软件配置管理组，
一合同管理组，和
一文档支持组。
5、级管理者评审所有的对组织外部的个人和组所作的软件项目约定。
6、项目的软件开发计划进行管理和控制。
在所有这些实践中术语“软件开发计划”习惯上指的是管理软件项目的全面的计划。采
用“开发”术语并不是有意排除软件维护项目或软件支持项目，应在每个项目的上下文中恰
当地解释该术语。
“进行管理和控制”意味着在给定时间（过去或现在）使用的工作产品的版本是已知的
（即版本控制），而且以受控的方式引进更改（即更改控制）。
如果希望有比“进行管理和控制”所蕴含的更高程度的控制，则工作产品可置于配置管
理的完备的纪律之下，正如在软件配置管理关键过程区域中所描述的。
执行能力
能力1
对软件项目存在文档化的经批准的工作陈述。
1、作陈述包括；
?? 工作的范围，
?? 技术目标和对象，
?? 对顾客和最终用户的识别，
这些实践中所指的最终用户是顾客指定的最终用户或最终用户的代表。
?? 要求实施的标准，
?? 安排的职责，
?? 成本和进度的约束及目标，
?? 软件项目和其它组织间的依赖关系。
其它组织的例子有；
一顾客，
一子承包商。和
一合资伙伴。
?? 资源限制和目标，和
?? 对开发和（或）维护的其它的约束和目标。
2、作陈述由下列人员评审；
?? 项目经理，
?? 项目软件经理，
?? 其它软件经理，和
?? 其它受影响的组。
3、工作陈述进行管理和控制。
能力2
?? 安排制定软件开发计划的职责。
1、目软件经理，直接工作或通过委托代表，协调项目的软件策划。


2、可追踪，可说明的方式分解对软件产品和活动的职责，并将其安排给软件经理。
软件工作产品的例子包括；
一适当时，交付给外部在客或最终用户的工作产品；
一供其它工程组使用的工作产品；和
一供软件工程组内部使用的主要工作产品。
能力3
为策划软件项目提供足够的资源和投资。
1、可能处，可以使用对正在策划的软件项目的应用领域有专门知识的有经验的个人来
制定软件开发计划。
2、得支持软件项目策划的工具合用。
支持工具的例子有：
一电子表格程序，
一估计模型，和
一项目策划和调度程序。
能力4 介入软件策划的软件经理、软件工程师和其它个人，在适用于其职责范围的软件
估计和策划规程方面受到培训。
执行的活动
活动1
软件工程组参加项目建议群组。
1、件工程组与下列各项工作有关：
?? 建议的准备和提交，
?? D 说明的讨论和提交，和
?? 对影响软件项目的约定作更改而进行的协商。
2、件工程组评审所建议的项目约定。
项目约定的例子包括：
一项目的技术目标和对象；
一系统和软件的技术解；
一软件预算、进度和资源；和
一软件标准和规程。
活动2
?? 在整个项目策划的早期阶段起动软件项目策划，此两项策划平行进行。
活动3
?? 在项目的整个生存期内，软件工程组和其它受影响的组一起参加整个项目的策划。
1、件工程组评审项目层的计划。
活动4
高级管理者参加按照已文档化的规程评审对组织外部的个人和组所作的软件项目约定。
活动5
识别或确定具有可管理规模的预先规定阶段的软件生存周期。
软件生存周期的例子有：
一瀑布型，
—重叠瀑布型，
一螺旋型，
—单型构造，和
—单个原型／重叠瀑布型。
活动6
?? 按照已文档化的规程制定项目的软件开发计划。
该规程一般规定：
1、件开发计划基于且遵守；
?? 顾客的标准，当合适时；
?? 项目的标准；
?? 经批准的工作陈述；和
?? 分配需求。
2、软件一有关组和其它工程组协商他们介入软件工程组活动的计划，把该项支持工作
编入预算，并对协议建立文档。
软件一有关组的例子有：
一软件质量保证组，
一软件配置管理组，和
一文档支持组。
其它工程组的例子有：
一系统工程组，
一硬件工程组，和
一系统测试组。
3、其它软件一有关组和其它工程组协商软件工程组介入其活动的计划，把该支持工作
编入预算，并对协议建立文档。
4、下列人员评审软件开发计划：
?? 项目经理，
?? 项目软件经理，
?? 其它软件经理，和
?? 其它受影响的组。
5、软件开发计划进行管理和控制。
活动7
对有关软件项目的计划建立文档。
在关键实践中，这个计划或计划的集合称为软件开发计划。
参考软件项目跟踪和监督关键过程区域的活动1 以便找到关于项目使用软件开发计划
的实践。
软件开发计划包括：
1、件项目的目的、范围、目标、和对象。
2、件生存周期的选择。
3、选的供开发和（或）维护软件用的规程、方法和标准的确定。
软件标准和规程的例子有；
一软件开发策划，
一软件配置管理，
一软件质量保证，
一软件设计，
一问题跟踪和解决，和
一软件测量。
4、开发软件工作产品的确定。
5、软件工作产品的规模估计和对软件工作产品的更改。
6、软件项目的工作量和成本的估计。
7、键计算机资源的预计使用情况。
8、件项目的进度，包括里程碑和评审的确定。
9、目软件风险的识别和评估。


测量与分析
测量1
进行测量并将测量结果用于确定SQA 活动的成本和进度状态。
测量的例子有：
—SQA 活动的里程碑的完成情况与计划作比较；
一在SQA 活动中所完成的工作、所化费的工作量和所消耗的资金与计划作比较；和
一产品审计和活动评审的次数与计划相比较。
验证实施
验证1
高级管理者定期参与评审SQA 活动。
高级管理者定期评审的主要目的是在合适的抽象层次上并以及时的方式了解和洞察软
件过程活动。评审间隔应该满足组织的需要，只要已存在报告例外情况的合适机制，间隔可
以长。
参考软件项目跟踪和监督关键过程区域的验证1 以便找到包括高级管理者监督评审的
典型内容的实践。
验证2
项目经理既定期地也事件驱动地参与评审SQA 活动。
参考软件项目跟踪和监督关键过程区域的验证2 以便找到包括项目管理者监督评审的
典型内容的实践。
验证3
独立于SQA 组的专家定期评审项目SQA 组的活动和软件工作产品。

等级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 活动。