本文作者在企业从事SQA工作，同时兼任SEPG的工作进行基于CMM3的过程改进，在实践过程中，对SQA的工作有了较多的想法和认识。本文是个人看法，请大家指教，如果要和本人联系，请发Email到：heqingemail@163.net。

二、SQA的理论探索

2.1、过程的;认识

我们都知道一个项目的主要内容是：成本、进度、质量；良好的项目管理就是综合三方面的因素，平衡三方面的目标，最终依照目标完成任务。项目的这三个方面是相互制约和影响的，有时对这三方面的平衡策略甚至成为一个企业级的要求，决定了企业的行为，我们知道IBM的软件是以质量为最重要目标的，而微软的“足够好的软件”策略更是耳熟能详，这些质量目标其实立足于企业的战略目标。所以用于进行质量保证的SQA工作也应当立足于企业的战略目标，从这个角度思考SQA，形成对SQA的理论认识。

软件界已经达成共识的：影响软件项目进度、成本、质量的因素主要是“人、过程、技术”。
首先要明确的是这三个因素中，人是第一位的。
现在许多实施CMM的人员沉溺于CMM的理论过于强调“过程”，这是很危险的倾向。这个思想倾向在国外受到了猛烈抨击，从某种意义上各种敏捷过程方法的提出就是对强调过程的一种反思。
“XP”中的一个思想“人比过程更重要” 是值得我们思考的。我个人的意见在进行过程改进中坚持“以人为本”，强调过程和人的和谐。
根据现代软件工程对众多失败项目的调查，发现管理是项目失败的主要原因。这个事实的重要性在于说明了“要保证项目不失败，我们应当更加关注管理”，注意这个事实没有说明另外一个问题“良好的管理可以保证项目的成功”。现在很多人基于一种粗糙的逻辑，从一个事实反推到的这个结论，在逻辑上是错误的，这种错误形成了更加错误的做法，这点在SQA的理解上是体现较深。
如果我们考证一下历史的沿革，应当更加容易理解CMM的本质。CMM首先是作为一个“评估标准”出现的，主要评估的是美国国防部供应商保证质量的能力。CMM关注的软件生产有如下特点：
质量重要
规模较大
这是CMM产生的原因。它引入了“全面质量管理”的思想，尤其侧重了“全面质量管理”中的“过程方法”，并且引入了“统计过程控制”的方法。可以说这两个思想是CMM背后的基础。
上面这些内容形成了我对软件过程地位、价值的基本理解；在这个基础上我们可以引申讨论SQA。

2.2、生产线的隐喻

如果将一个软件生产类比于一个工厂的生产。那么生产线就是过程，产品按照生产线的规定过程进行生产。SQA的职责就是保证过程的执行，也就是保证生产线的正常执行。
抽象出管理体系模型的如下，这个模型说明了一个过程体系至少应当包含“决策、执行、反馈”三个重要方面。QA的职责就是确保过程的有效执行，监督项目按照过程进行项目活动；它不负责监管产品的质量，不负责向管理层提供项目的情况，不负责代表管理层进行管理，只是代表管理层来保证过程的执行。

2.3、SQA和其他工作的组合

在很多企业中，将SQA的工作和QC、SEPG、组织级的项目管理者的工作混合在一起了，有时甚至更加注重其他方面的工作而没有做好SQA的本职工作。
根据hjhza 的意见“中国现在基本有三种QA（按照工作重点不同来分）：一是过程改进型，一是配置管理型，一是测试型”。我个人认为是因为SQA工作和其他不同工作组合在一起形成的。
下面根据本人经验对它们之间的关系进行一个说明。

2.4、QA和QC

两者基本职责
QC：检验产品的质量，保证产品符合客户的需求；是产品质量检查者；
QA：审计过程的质量，保证过程被正确执行；是过程质量审计者；
注意区别检查和审计的不同
检查：就是我们常说的找茬，是挑毛病的；
审计：来确认项目按照要求进行的证据；仔细看看CMM中各个KPA中SQA的检查采用的术语大量用到了“证实”，审计的内容主要是过程的；对照CMM看一下项目经理和高级管理者的审查内容，他们更加关注具体内容。

对照上面的管理体系模型，QC进行质量控制，向管理层反馈质量信息；QA则确保QC按照过程进行质量控制活动，按照过程将检查结果向管理层汇报。这就是QA和QC工作的关系。在这样的分工原则下，QA只要检查项目按照过程进行了某项活动没有，产出了某个产品没有；而QC来检查产品是否符合质量要求。如果企业原来具有QC人员并且QA人员配备不足，可以先确定由QC兼任QA工作。但是只能是暂时的，独立的QA人员应当具备，因为QC工作也是要遵循过程要求的，也是要被审计过程的，这种混合情况，难以保证QC工作的过程质量。

2.5、QA和SEPG

两者基本职责

SEPG：制定过程，实施过程改进；
QA： 确保过程被正确执行

SEPG应当提供过程上的指导，帮助项目组制定项目过程，帮助项目组进行策划；从而帮助项目组有效的工作，有效的执行过程。如果项目和QA对过程的理解发生争持，SEPG作为最终仲裁者。为了进行有效过程改进，SEPG必须分析项目的数据。

QA本也要进行过程规范，那么所有QA中最有经验、最有能力的QA可以参加SEPG，但是要注意这两者的区别。

如果企业的SEPG人员具有较为深厚的开发背景，可以兼任SQA工作，这样利于过程的不断改进；但是由于立法、执法集于一身也容易造成SQA过于强势，影响项目的独立性。管理过程比较成熟的企业，因为企业的文化和管理机制已经健全，SQA职责范围的工作较少，往往只是针对具体项目制定明确重点的SQA计划，这样SQA的审计工作会大大减少，从而可以同时审计较多项目。

另一方面，由于分工的细致化，管理体系的复杂化，往往需要专职的SEPG人员，这些人员要求了解企业的所有管理过程和运作情况，在这个基础上才能统筹全局的进行过程改进，这时了解全局的SQA人员就是专职SEPG的主要人选；这些SQA人员将逐渐的转化为SEPG人员，并且更加了解管理知识，而SQA工作渐渐成为他们的兼职工作。

这种情况在许多CMM5企业比较多见，往往有时看不见SQA人员在项目组出现或者很少出现，这种SEPG和SQA的融合特别有利于组织的过程改进工作。SEPG确定过程改进内容，SQA计划重点反映这些改进内容，从保证有效的改进，特别有利于达到CMM5的要求。从这个角度，国外的SQA人员为什么高薪就不难理解了，也决定了当前中国SQA人员比较被轻视的原因；因为管理过程还不完善，我们的SQA人员还没有产生这么大的价值嘛！

2.6、QA和组织级的监督管理

有的企业为了更好的监督管理项目，建立了一个角色，我取名为“组织级的监督管理者”，他们的职责是对所有项目进行统一的跟踪、监督、适当的管理，来保证管理层对所有项目的可视性、可管理性。

为了有效管理项目，“组织级的监督管理者”必须分析项目的数据。

他们的职责对照上图的模型，就是执行“反馈”职能。

QA本身不进行反馈工作，最多对过程执行情况的信息进行反馈。

SQA职责最好不要和“组织级的项目管理者”的职责混合在一起，否则容易出现SAQ困境：一方面SQA不能准确定位自己的工作，另一方面过程执行者对SQA人员抱有较大戒心。

如果建立了较好的管理过程，那么就会增强项目的可视性，从而保证企业对所有项目的较好管理；而QA来确保这个管理过程的运行。

三、SQA的工作内容和工作方法

3.1、 计划

针对具体项目制定SQA计划，确保项目组正确执行过程。制定SQA计划应当注意如下几点：
有重点：依据企业目标以及项目情况确定审计的重点
明确审计内容：明确审计哪些活动，那些产品
明确审计方式：确定怎样进行审计
明确审计结果报告的规则：审计的结果报告给谁

3.2、审计/证实

依据SQA计划进行SQA审计工作，按照规则发布审计结果报告。
注意审计一定要有项目组人员陪同，不能搞突然袭击。双方要开诚布公，坦诚相对。
审计的内容：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。

3.3、问题跟踪
对审计中发现的问题，要求项目组改进，并跟进直到解决。

四、SQA的素质

过程为中心：应当站在过程的角度来考虑问题，只要保证了过程，QA就尽到了责任。

服务精神：为项目组服务，帮助项目组确保正确执行过程
了解过程：深刻了解企业的工程，并具有一定的过程管理理论知识
了解开发：对开发工作的基本情况了解，能够理解项目的活动
沟通技巧：善于沟通，能够营造良好的气氛，避免审计活动成为一种找茬活动。

从CMM2级中包含的6个关键过程域来看，无论是需求管理、软件项目计划、软件项目跟踪与监控，还是软件子合同管理、软件配置管理，都不同程度地存在于我们现在正在进行的软件项目开发过程中，对于它们的了解我们已经不再陌生，只有SQA这个关键过程域，是在我们准备以CMM2级要求的关键过程域为基础进行软件过程改进前未接触过的。

在很多软件企业中还没有与之相对应的人员和工作方法，整套关注软件开发过程的软件质量保证体系还没有建立起来。所以，在企业以CMM2级关键过程域为参考进行软件过程改进时，SQA往往是一个难点，直接涉及到组织结构的变化。

实施SQA的目的

软件质量保证的目标是以独立审查方式，从第三方的角度监控软件开发任务的执行,就软件项目是否正遵循已制定的计划、标准和规程给开发人员和管理层提供反映产品和过程质量的信息和数据，提高项目透明度，同时辅助软件工程组取得高质量的软件产品。主要包括以下四个方面：

● 通过监控软件开发过程来保证产品质量;

● 保证开发出来的软件和软件开发过程符合相应标准与规程；

● 保证软件产品、软件过程中存在的不符合问题得到处理,必要时将问题反映给高级管理者；

● 确保项目组制定的计划、标准和规程适合项目组需要，同时满足评审和审计需要;

除了以上四点之外，我们还希望SQA能作为软件工程过程小组（SEPG）在项目组中的延伸，能够收集项目中好的实施方法和发现实施不利的原因，为修改企业内部软件开发整体规范提供依据，为其他项目组的开发过程实施提供先进方法和样例。

对SQA人员的素质要求

1. SQA人员(有时简称SQA)要有很强的沟通能力。从实施SQA的目的中可以看出，SQA不在项目中，是独立于软件项目的第三方，但他要了解项目的开发过程和进度，捕捉到项目中不符合要求的问题，这就要求SQA能够深入项目，和软件开发经理以及项目组中的开发人员保持很好的沟通，这样才能及时获得真实的项目情况。

2. SQA要熟悉软件开发过程。作为SQA，既然要确保项目组制定的计划、标准和规程，要符合项目组要求，那么SQA首先自己就要了解软件项目开发过程，以及企业内部已经有的开发过程规范。

3. SQA本身要有很强的计划性。SQA一方面要监督软件项目组编写计划，另一方面SQA自身的工作也要有计划，并且能够按照计划开展工作。

4. SQA要能应对繁杂的工作。作为SQA，在跟踪项目进行过程的时候要对项目组的很多工作产品进行审计，而且会参与项目组中的多种活动。同时一个SQA还有可能会面对多个项目组，所以任务相对繁杂细碎，这就要求SQA在处理这些事物的时候要耐心细致。

5. SQA要客观，有责任心。作为第三方对项目过程进行监督，SQA要能保持自己的客观性，不能一味讨好项目经理，也不能成为项目组中的宪兵，否则会影响工作的开展。对于项目组中多次协调解决不了的问题，能够向项目的高层经理进言，完成SQA的使命。

以上五点是作为SQA应该具备的基本素质，除此之外，一个好的SQA还应该在软件开发过程中作为开发人员或测试人员参与过一个或多个环节，这样他们才能在过程监督中比较准确地抓住重点，同时他们的意见和提出的解决办法也会更贴近项目组，容易被项目组接受。

SQA人员的组成

软件企业中的SQA人员既可以由全职人员担任，也可以由企业内具有相关素质、经过SQA培训的人员兼职担任。由此组成的SQA小组可能是一个真正的物理上存在的独立部门，也可以是一个逻辑上存在的平台。但不管是真正的独立部门还是逻辑上的平台，它都需要有一个灵魂人物——SQA小组组长，来组织SQA小组的日常活动。

在给一个项目组分配负责监督其项目过程的SQA时，一定要注意一点：就是该项目的SQA不能是该项目组的开发人员、配置管理人员或测试人员，一个项目的SQA除了监控项目过程，完成SQA相关工作以外，不应该参与项目组的其他实质性工作，否则他会与项目组捆绑在一起，很难保持客观性。

SQA工作的内容

SQA的工作内容主要包括以下六类：

1. 与SQA计划直接相关的工作：SQA在项目早期要根据项目计划制定与其对应的SQA计划，定义出各阶段的检查重点，标识出检查、审计的工作产品对象，以及在每个阶段SQA的输出产品。定义越详细，对于SQA今后的工作的指导性就会越强，同时也便于软件项目经理和SQA组长对其工作的监督。编写完SQA计划后要组织SQA计划的评审，并形成评审报告，把通过评审的SQA计划发送给软件项目经理、项目开发人员和所有相关人员。

2. 参与项目的阶段性评审和审计：在SQA计划中通常已经根据项目计划定义了与项目阶段相应的阶段检查，包括参加项目在本阶段的评审和对其阶段产品的审计。对于阶段产品的审计通常是检查其阶段产品是否按计划按规程输出并内容完整，这里的规程包括企业内部统一的规程也包括项目组内自己定义的规程。但是SQA对于阶段产品内容的正确性一般不负责任检查，对于内容的正确性通常交由项目中的评审来完成。SQA参与评审是从保证评审过程有效性方面入手，如参与评审的人是否具备一定资格、是否规定的人员都参见了评审、评审中对被评审的对象的每个部分都进行了评审、并给出了明确的结论等等。

3. 对项目日常活动与规程的符合性进行检查: 这部分的工作内容是SQA的日常工作内容。由于SQA独立于项目组，如果只是参与阶段性的检查和审计很难及时反映项目组的工作过程，所以SQA也要在两个阶段点之间设置若干小的跟踪点，来监督项目的进行情况，以便能及时反映出项目组中存在的问题，并对其进行追踪。如果只在阶段点进行检查和审计，即便发现了问题也难免过于滞后，不符合尽早发现问题、把问题控制在最小的范围之内的整体目标。

4. 对配置管理工作的检查和审计：SQA要对项目过程中的配置管理工作是否按照项目最初制定的配置管理计划进行监督，包括配置管理人员是否定期进行该方面的工作、是否所有人得到的都是开发过程产品的有效版本。这里的过程产品包括项目过程中产生的代码和文档。

5. 跟踪问题的解决情况: 对于评审中发现的问题和项目日常工作中发现的问题，SQA要进行跟踪，直至解决。对于在项目组内可以解决的问题就在项目组内部解决，对于在项目组内部无法解决的问题，或是在项目组中跟催多次也没有得到解决的问题，可以利用其独立汇报的渠道报告给高层经理。

6. 收集新方法，提供过程改进的依据：此类工作很难具体定义在SQA的计划当中，但是SQA有机会直接接触很多项目组，对于项目组在开发管理过程中的优点和缺点都能准确的获得第一手资料。他们有机会了解项目组中管理好的地方是如何做的，采用了什么有效的方法，在SQA小组的活动中与其他SQA共享。这样这些好的实施实例就可以被传播到更多的项目组中。对于企业内过程规范定义的不准确或是不方便的地方，软件项目组也可以通过SQA小组反映到软件工程过程小组，便于下一步对规程进行修改和完善。

SQA与几类角色间的关系

一个企业内的部门设置可能会各有不同，但是很多角色设置是相同的，从一个项目的SQA出发，我们可以把SQA与其他相关角色的关系表示为下图: 以上图示只说明SQA与高层经理、项目组和其他相关组之间的关系，并不是以上几个角色之间所有关系的描述，所以即便项目组会直接向高层经理汇报，但与SQA无直接关系，在图中就没有表现出来。

SQA工作中常见的几个问题

1. 最初给项目组配置SQA人员的时候，SQA的价值不被认可因为是新工作的初次开展，已经习惯了自己管理项目，向高层经理汇报的项目组难免会有抵触情绪。要从两个方面解决这个问题：一方面，从组织的角度，要明确SQA的角色及其合法性; 另一方面，SQA也要以其专业的工作赢得项目组认可，为项目组增加价值。

2. 一个全职的SQA可以同时兼任多少个项目的SQA工作对于不同的项目规模和组织管理方式，这个问题会有不同的答案，根据实施中的一些经验总结，通常在第一次实施时，承担一个20人左右的项目组的SQA工作需要占用一个人30%左右的工作量，随着SQA的成熟，这个比例会降低到15%。对于一个10人以内的项目组，SQA需要投入其10%左右的工作量。当然，项目越大SQA的投入就越多。

3. SQA与项目组的关系难处理对于SQA与项目组的关系，应该遵循以下两条原则: 要在过程方面成为项目组的严师，有错必纠，但不能有错全报；要做项目组的朋友，但不能对项目组包庇纵容。

4. 项目组有了SQA，可是需求文档和设计文档的质量还是不高对不起，这不是SQA的直接工作范围。提高需求和设计的质量，要从人员培训和严格评审入手，让有经验有资格的人来完成需求和设计文档。SQA只能从规程符合方面进行监督。

总之，在软件企业中建立SQA体系，是软件项目管理由人治到法治的一个必经阶段，也是软件企业以CMM模型为参考，进行软件过程改进中一个不可缺少的部分。软件企业只要真正建立了SQA规范，培养了专业的SQA人员就会真正从中体会到它的好处。