SQA到底是什么？

SQA到底是什么？

   一、 前言

　　在企业从事SQA工作，同时兼任SEPG的工作进行基于CMM3的过程改进，在实践过程中，对SQA的工作有了较多的想法和认识。本文是个人看法，请大家指教。

　　二、SQA的理论探索

　　2.1、过程的 认识

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

　　软件界已经达成共识的：影响软件项目进度、成本、质量的因素主要是 &ldquo人、过程、技术&rdquo。首先要明确的是这三个因素中，人是第一位的。

　　现在许多实施 CMM的人员沉溺于CMM的理论过于强调&ldquo过程&rdquo，这是很危险的倾向。这个思想倾向在国外受到了猛烈抨击，从某种意义上各种敏捷过程方法的提出就是对强调过程的一种反思。 &ldquoXP&rdquo中的一个思想&ldquo人比过程更重要&rdquo 是值得我们思考的。我个人的意见在进行过程改进中坚持&ldquo以人为本&rdquo，强调过程和人的和谐。

　　根据现代软件工程对众多失败项目的调查，发现管理是项目失败的主要原因。这个事实的重要性在于说明了 &ldquo要保证项目不失败，我们应当更加关注管理&rdquo，注意这个事实没有说明另外一个问题&ldquo良好的管理可以保证项目的成功&rdquo。现在很多人基于一种粗糙的逻辑，从一个事实反推到的这个结论，在逻辑上是错误的，这种错误形成了更加错误的做法，这点在SQA的理解上是体现较深。

　　如果我们考证一下历史的沿革，应当更加容易理解 CMM的本质。CMM首先是作为一个&ldquo评估标准&rdquo出现的，主要评估的是美国国防部供应商保证质量的能力。CMM关注的软件生产有如下特点：

　　(1)质量重要

　　(2)规模较大

　　这是 CMM产生的原因。它引入了&ldquo全面质量管理&rdquo的思想，尤其侧重了&ldquo全面质量管理&rdquo中的&ldquo过程方法&rdquo，并且引入了&ldquo统计过程控制&rdquo的方法。可以说这两个思想是CMM背后的基础。

　　上面这些内容形成了我对软件过程地位、价值的基本理解在这个基础上我们可以引申讨论 SQA。

　　2.2、生产线的隐喻

　　如果将一个软件生产类比于一个工厂的生产。那么生产线就是过程，产品按照生产线的规定过程进行生产。 SQA的职责就是保证过程的执行，也就是保证生产线的正常执行。

　　抽象出管理体系模型的如下，这个模型说明了一个过程体系至少应当包含 &ldquo决策、执行、反馈&rdquo三个重要方面。

　　QA的职责就是确保过程的有效执行，监督项目按照过程进行项目活动它不负责监管产品的质量，不负责向管理层提供项目的情况，不负责代表管理层进行管理，只是代表管理层来保证过程的执行。

　　

　　2.3、SQA和其他工作的组合

　　在很多企业中，将 SQA的工作和QC、SEPG、组织级的项目管理者的工作混合在一起了，有时甚至更加注重其他方面的工作而没有做好SQA的本职工作。

　　根据 hjhza 的意见&ldquo中国现在基本有三种QA(按照工作重点不同来分)：一是过程改进型，一是配置管理型，一是测试型&rdquo。我个人认为是因为SQA工作和其他不同工作组合在一起形成的。

　　下面根据本人经验对它们之间的关系进行一个说明。

　　2.4、QA和QC

　　两者基本职责

　　QC：检验产品的质量，保证产品符合客户的需求是产品质量检查者

　　QA：审计过程的质量，保证过程被正确执行是过程质量审计者

　　注意区别检查和审计的不同

　　检查：就是我们常说的找茬，是挑毛病的

　　审计：来确认项目按照要求进行的证据仔细看看CMM中各个KPA中SQA的检查采用的术语大量用到了&ldquo证实&rdquo，审计的内容主要是过程的对照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和组织级的监督管理

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

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

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

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

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

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

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

　　3.1、 计划

　　针对具体项目制定 SQA计划，确保项目组正确执行过程。制定SQA计划应当注意如下几点：

　　有重点：依据企业目标以及项目情况确定审计的重点

　　明确审计内容：明确审计哪些活动，那些产品

　　明确审计方式：确定怎样进行审计

　　明确审计结果报告的规则：审计的结果报告给谁

　　3.2、审计/证实

　　依据 SQA计划进行SQA审计工作，按照规则发布审计结果报告。

　　注意审计一定要有项目组人员陪同，不能搞突然袭击。双方要开诚布公，坦诚相对。

　　审计的内容：是否按照过程要求执行了相应活动，是否按照过程要求产生了相应产品。

　　3.3、问题跟踪

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

　　四、SQA的素质

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

　　服务精神：为项目组服务，帮助项目组确保正确执行过程

　　了解过程：深刻了解企业的工程，并具有一定的过程管理理论知识

　　了解开发：对开发工作的基本情况了解，能够理解项目的活动

　　沟通技巧：善于沟通，能够营造良好的气氛，避免审计活动成为一种找茬活动。

序号	实践名称	描述	技术方法	备注	工作产品示例	子实践	相关过程域
SG1	开发客户需求	收集干系人需要、期望、限制及接口，并转换成客户需求。
SP1.1	诱导需要	诱导干系人提出有关产品生命周期各阶段的需要、期望、限制及接口	1.技术展示 2.接口控制工作组 3.技术控制工作组 4.中间时期的项目审查 5.从最终用户获取问卷调查，访谈和情景（运作，维持和发展） 6.操作，维持和发展的演练和最终用户任务分析 7.质量属性与利益相关者启动研讨会 8.原型和模型 9.头脑风暴 10.市场调查 11.适用版本的试用 12.由文档、标准或规格等来源中抽取 13.观察现行产品、环境及工作过程的样式 14.用例 15.提供小增量“垂直截分”的产品功能 16.经营案例分析 17.采取反向工程（针对现有产品） 18.客户满意度调查	可能未被客户识别的需求来源： 1.经营策略 2.标准 3.经营环境 4.技术 5.现有产品或产品组件（可复用产品组件） 6.监督管理的规程	需求分析引导出的各项活动的结果	与相关干系人一起参与，并使用方法，以诱导出需求、期望、限制及外部接口。
SP1.2	将利益共享着的需要转化为客户需求	转换干系人的需求、期望、限制及接口为客户需求			1.客户需求 2.执行验证时的客户限制 3.执行确认时的客户限制	1.转换干系人的需要、预期、限制及接口，成为客户需求。 2.建立和维护用户功能和质量属性需求的优先级列表。划分优先级后能够帮助确立项目，迭代，或者增量模型。这种优先级策略确保了至关重要的功能和质量属性尽快得到解决。 3.定义验证及确认时的限制。
SG2	开发产品需求	调整并详细说明客户需求，以开发产品级产品组件需求。		配置需求于茶品组件，包括对象、人员及过程。在迭代或者增量开发过程中，可以分配成迭代和增量的获取过程。
SP2.1	建立产品和产品组件需求	以客户需求为基础，建立并维护产品与产品组件的需求。		质量属性测度的例子包括如下： 在一秒内相应，百分之九十九的时间系统都是可使用的，在不超过一个职员一周的工作量内实现一个变化。 需求之间的关系可以帮助评估变化的影响。	1.衍生需求 2.产品需求 3.产品组件需求 4.架构需求，定义约束了产品工件的关系	1.以专业术语开发产品与产品组件设计的需求。针对产品架构设计所需的重要的产品质量和绩效，开发架构需求。 2.由设计决策衍生需求。技术的选用会引进其它的需求。 3.开发架构需求捕获重要的质量属性，以及建立产品架构和设计需要的质量属性测度。 4.建立并维护需求间的关联性，并考虑在变更管理和需求配置时的影响。
SP2.2	配置产品组件需求	配置产品组件需求		产品架构为如何将产品需求分配给产品组件提供了基准	1.需求配置表 2.暂时性的需求配置 3.设计限制 4.衍生需求 5.衍生需求间的关系	1.配置需求于功能。 2.配置需求与产品组件和架构。 3.配置设计限制于产品组件和架构。 4.配置需求于交付增量 5.记录已配置需求间的关系。	技术解决方案
SP2.3	识别接口需求	识别接口需求，定义功能之间（或对象之间）的接口。功能接口肯能衍生出替代方案的开发，替代方案在技术解决方案过程域中描述。			1.接口需求	1.识别产品内部及外部的接口。 2.开发确定接口的需求。
SG3	分析并确认需求
SP3.1	建立操作概念及场景	场景一般而言是指使用产品时可能发生的事件顺序，以明确说明干系人的某些需要。			1.操作概念 2.产品或产品组件安装、操作、维护及支持概念。 3.销毁概念。 4.使用案例 5.依时间演化的场景 6.新需求
SP3.2	建立必要的功能定义和质量属性	定义需要的功能和质量属性的一种方法是用被有些人成为“功能分析”描述产品的作用，建立分析场景。功能描述可以包括行动，顺序，输入，输出等。			1.需要的功能和质量属性的定义 2.功能架构 3.活动图和用例 4.对象导向分析和已识别的服务或方法 5.架构上重要的质量属性要求。
SP3.3	分析需求	分析需求以确保其必要性和充分性			1.需求缺陷报告 2.用来解决缺陷的需求变更建议 3.关键需求 4.技术绩效度量
SP3.4	分析需求以取得平衡	分析需求，并在干系人的需要和时间限制间取得平衡；干系人的需要和限制可说明成本，进度，绩效，功能，再使用的组件、维护能力，或风险			1.需求相关风险的评价
SP3.5	确认需求	确认需求以确保最终产品在使用者环境下如期的运行。		1.分析 2.模拟 3.原型 4.示范	1.分析方法和结果的记录