[分享][原创]CTO思考之三-关于质量保证部的设想

关于质量保证部的设想

部门：总裁会

目的：为筹备质量保证部进行思想交流，不包括部门建设计划的商讨。

期望的读者：总裁会成员，部门经理联席会成员

作者：邱嘉文

时间：2000-12-15至2000-12-18

反馈意见记录：

意见人	意见	提出时间

一． 背景

1． 公司人员、产品开发规模作了较大扩充，经过了一年时间的运作，引入了部分质量保证措施，如测试专业分工，分析设计评审，工作流程、工作指南文件的建立和试行等等。对规范开发管理，提高质量意识，打下了积极的基础。

2． 公司决策层领导充分认识到同望产品质量的重要性，提出了“精品战略”作为同望未来产品发展的基调之一。并积极倡导按照软件工程的理论学习和实践应用，确立了通过CMM认证的企业能力提升目标，并在制定学习、培训，逐步实践应用的计划。

3． 公司老产品在销售后用户使用过程中，暴露了较多的质量问题，这与老产品在开发过程中未能采取有效的质量保证措施是密切相关的。在新开产品项目管理中，质量保证措施明显不够有效，质保人员及其专业素养严重不足，成为新产品开发中的重大质量风险因素。

4． 由于公司处于快速成长阶段，对质量保证的投入有一个逐步加强的过程。因此，在产品质量问题和质量管理过程问题已经暴露出来的时候来加强质量管理是一种不得已的“亡羊补牢”的办法。由于质量保证问题本身的敏感性和技术上的复杂性决定了质量保证活动开展必须慎重。所以开展质量保证活动成了公司非常紧迫又需非常慎重的工作，质量保证的投入投向何处，如何投入是公司决策层迫切需要明确的问题。

二． 软件质量保证SQA的基本观念

1． 质量的前提是度量

质量控制可以等同于差异的控制：所有产品的特性以及生产这些特性的过程与事先需求的差异应该最小或一致。

为了控制差异必须能度量差异： 必须对事前的需求和生产过程中的结果要能分别进行定量测量和描述，两者比较才能找到差异，然后才能想办法控制和消除差异。

为了度量差异必须建立度量机制，积累度量经验：必须决定对产品及其生产过程进行哪些方面的测量，并对具体的产品和过程对象实施测量，并对测量数据进行管理、分析，检讨度量模型的好坏，改进度量模型。

“定性”的东西只是质量意识，只有“定量”的东西才是真正的质量管理。

2． 质量的内容有多层

根据度量对象不同分：包括产品的质量和过程的质量。产品是过程制造出来的，过程的质量决定了产品的质量。

根据度量时期不同分，包括软件生命周期内各个阶段的质量。最顶层包括软件营销和软件开发两个大环节。营销环节可细分为产品包装发布、产品广告销售、产品使用服务、产品需求调查、产品策划定位、产品需求定义；开发环节可细分为：产品需求定义，产品系统分析，产品系统设计，产品模块开发，产品系统测试，产品包装发布。软件营销环节和开发环节在产品包装和需求定义两个小环节上交接，形成一个周期循环的过程，在该循环的任何相邻两个阶段对产品的定义或实现都将直接暴露出差异，如何管理和控制这些差异，正是软件全过程质量的内容。因此，软件质量应包括：软件的需求调查质量、策划质量、需求定义质量、分析质量、设计质量、实现质量、测试质量、包装质量、推销质量、使用服务质量等10项完整的概念。任何一个环节的质量问题，都会影响所有其他环节的质量。

3． 质量的成本要比较

“进行质量保证活动需要付出额外资金，没有质量保证活动仍然可以实施软件，因此进行软件质量保证活动增加了软件实施成本。”这是我们身边明显存在的一个误区。当然，没有计划、没有技术指导，不切实际的质量保证活动不仅仅会增加软件实施成本，而且会给软件的生存带来极大的危害也确实是事实，但这不应该是推导出这个误区存在的理由。

进行质量保证活动确实需要付出额外资金。但不管是否进行质量保证活动，由发现、鉴定和修复软件缺陷引发的成本始终是存在的，这是软件质量本身的成本。质量保证活动的任务就是保证软件缺陷在其产生之后就立即被发现和鉴定，并尽快得到修复。认识质量成本要比较有质量保证活动和没有质量保证活动两种情况下的质量成本，才能发现付出额外的质保活动资金所得到的回报。以下两个理论是推行质量保证活动能大大节约软件质量成本的基本论据：

a. 错误放大理论：软件生命周期内前一阶段的一个错误，会引发后一阶段的数量级递增个数的错误；

b. 成本放大理论：修复软件生命周期内靠后阶段上的一个错误和修复靠前一阶段上的一个错误所付出的代价相比的结果，是呈几何级数递增的。

三． 现状的分析

目前，公司正式成立的直接进行质量保证活动的部门有：开发部测试组，包括测试组主任李娜在内共有6名成员，除李娜在公司有四个项目（Road2000,Proj2000,Bid2000,MP2000）约三年的测试工作经验之外，其他人员经验相对薄弱。公司目前正式开展过的质量保证活动包括：系统测试，产品验收，产品策划审核，需求说明评审，需求分析评审，详细设计评审等六项。除系统测试工作直接对提高产品质量起到明显效果之外，其他活动暂时只对提高质量意识起到作用。

系统测试活动状况：所有测试人员没有接受过专业测试培训，全靠自学理论书籍和摸索测试方法和经验，尚未建立正式的测试流程，正在整理和贯彻测试要求文档的提交工作，但由于开发员配合不力和测试流程不健全，该项工作暂时不能顺利进行。对测试人员本身的管理也基本处于自发状态，测试人员对提高自身素质，结合实际学习先进理论的积极性不高。测试组引进的辅助测试工具SQA和错误追踪系统的使用情况是：SQA工具在MP2000的测试工作中得到了实际的运用，对提高部分测试数据的录入，操作步骤重现起到了一定作用，提高了一定效率。但也发现SAQ工具控制适应性的局限，一定程度影响了自动测试的效果。错误追踪系统由于意外原因数据库在建立后被误删，使之没有真正运行起来。同时也反映了该系统不够成熟。

其他产品验收和阶段评审活动状况：由于这些活动被正式的列入实际工作流程，并开展实施，对各阶段工作人员起到了明确的质量要求的警示作用，对工作人员重视文档工作起到了积极的作用。但是，由于以下种种原因：

1． 员工实际的工作方法和制定的工作规范所适应的面向对象工作方法不一致；

2． 对员工学习掌握面向对象工作方法的培训和实践锻炼不够；

3． 员工实际的工作方法本身缺乏规范化的要求；

4． 产品项目工期紧，进行一线开发的人员工作压力过重；

5． 评审人员本身没有任何培训；

6． 评审人员本身没有软件技术评审经验；

7． 软件评审人员和高级管理者角色重叠；

8． 软件评审人员不够专职，没有花费足够的时间来理解“软件”本身。

我们进行的评审活动远远没能达到应有的作用。其中关键的原因是我们对质量保证人员的要求存在严重误解：认为他们是“站在高处，监视着软件开发过程进展和软件产品逐渐成型”的那帮人。其实，SQA小组的那帮人，应该和一线开发人员一样，他们应该是“另外一批对软件产品及其过程有深刻认识和理解的家伙”。他们甚至应该比那些“一针一线”编出软件的人更深入，细致地理解软件产品及其过程，他们随时会将发现的差异向高级管理者汇报。高级管理者当然不可能是称职的SQA小组成员。在CMM文献的推荐中，对编码实现阶段的SQA管理人员，最合适的人选莫过于决不参与编码实现的系统分析和设计人员。

公司目前质量保证工作的现状应该可以概括为：意识强烈、观念模糊、基础薄弱、人员欠缺、知识贫乏、效果微小。作为一个高速发展的以软件产品服务为主营服务的公司，这无疑是一个极端危险的状况。

四． 成立质量保证组的可行性

背景和现状分析的情况已经充分证实了公司成立质量保证组的必要性和紧迫性。但公司是否适合在目前现状下立即成立质量保证部或者在何时、以何步骤筹建质量保证部，目前又能做些什么准备工作呢？

1． 技术可行性

目前，公司成立质量保证部在技术上存在以下主要有利因素：

l 有相对充足的理论指导；

l 有决策层领导充分重视和支持；

l 正在实施CMM2级认证的关键域之一：引入项目管理策略；

l 正在进行开发文档规范化管理活动；

l 测试组人员经验有一定班底。

在技术上的主要不利因素包括：

l 全员尤其在管理层对质量保证观念不够统一，对SQA活动本身理解不够；

l 缺少一个理论实践经验都比较丰富，对公司现状有一定认识的管理层干部；

l 面向过程的开发技术和面向对象的开发规范仍然存在不配套问题，导致不能建立统一的度量和评测标准；

l 懂开发技术，有开发经验的质量保证人员基本上是空白；

l 来自市场对产品推出数量和时间的压力和产品需求版本规划不相适应，导致一线开发及其管理压力过大，加大了质量保证活动开展的困难。

根据以上分析，公司目前在技术上暂时还不具备成立质量保证部，全面推行SQA活动的可行性，但已经具备推行某些SQA活动的可行性，如：系统测试，SQA技术培训，人才募集和培养，与开发方法无关的质量指标度量，适当的正式技术复审（FTR）等等。这些活动可以以现在的测试组为班底，补充一定数量人员，开展一些内训和外训就能开展起来。

2． 经济可行性

成立独立的质量保证部，开展全过程的SQA活动，需要一批专门的具有较高素质的人才。人才的招聘、培训、薪酬、福利、工作环境消耗将是一笔不小的成本支出。就目前的产品规模来评估，成立一个20人规模的质量保证部门是基本的需要。估计组建这样一支SQA队伍需要费用支出一年在150-200万元左右。就目前公司经济实力情况来看，是完全能够承受的。就长远来看，这笔支出肯定可以从日后软件维护升级、用户满意度提高促进市场占有率方面获得丰厚回报。可以认为成立独立的质量保证部，在经济上是基本可行的。

3． 质量保证部成立的准备工作和时机

要正式成立质量保证部，公司必须解决技术可行性的头三项不利因素影响。问题主要集中在管理层的观念和人员上。因此准备工作的主要任务就是要解决管理层观念和人员空缺问题。管理层的观念包括公司各职能部门的经理，也就是部门经理联席会的所有成员对SQA活动的认识和理解的问题，而不是简单停留在表面或深层对质量问题的重视，口头对加强质量管理的宣讲和鼓动上。所以需要开展的第一项重要的工作，就是管理层的SQA活动知识、方法的普及教育和培训工作。其次，为了能提高全员的SQA观念，应大力倡导执行层干部努力自学SQA知识、方法，并在实践中积极尝试运用，对积极表现，效果显著者列入部门经理的普及教育和培训之列，作为未来质量保证部部门经理的培养对象重点培养。最后，在扩充开发部测试组实力，招聘新人加盟时，应该主要留意具有全面质量保证意识和能力方面的人才，彻底放弃“对测试人员技术要求可以偏低，到公司稍加锻炼就能上手”的错误观念。在岗位级别、薪资报酬方面，真正把质量保证人员放到与开发人员同等位置上来。

根据CMM2级认证需要进行的关键过程域（KPA）要开展的工作建议，SQA活动也是被列入必须开展的工作之一。根据专家的经验，通过CMM2级认证的过程可能需要2-3年，甚至5年的时间。在目前公司开展项目管理的经验和效果尚未进阶的状况下，首先应花半年到一年的时间落实项目管理工作，其中包括测度和度量、估算、风险分析、进度安排、跟踪和控制等活动的开展，争取在人员、问题和过程三方面的管理上走上正确轨道。在这半年到一年的时间中，积极进行质量保证部的各项准备工作。在对项目管理工作走上正轨，通过内部评测后，正式成立质量保证部门，全面开展SQA工作的时机就自然到来。

五． 预想

虽然目前公司成立质量保证部的可行性仍不够充分，但这不影响对未来理想状况下，质量保证部门的运作情况做一个想象，相反，这种想象会促使我们不断地找出差距，树立工作目标。假设三年后公司各方面管理工作基本配套，公司质量保证部门已经开展了SQA活动两年多的情况下，公司质量保证部门应该进入相对成熟的阶段，那时，与质量保证部门相关的公司活动情景应该是：

质量保证部有一名管理层干部：质保部经理。在执行层，公司每一个在生的产品都将有一个专职的质量保证小组，对其生命周期内的每一个环节进行保护性活动。每个质量保证小组常设一名组长（可称为质量经理或测试经理，注意，绝对不由产品经理或开发经理同时兼任，但应从产品经理、开发经理、测试员中培养出来。成立质量保证小组的初衷，就是要把产品经理和开发经理的有关质量跟踪和评测的工作分工出来，由专职的质量经理来负责，使产品经理和开发经理有足够经理投入到一线开发工作中去，从而实现一线的开发工作和二线的保护性工作的分离，提高软件过程的可靠性，最终提高产品质量。），其他组员随生命周期不同，人选、数量可动态调整和由非周期内主干人员临时专职担任。

在需求调查阶段，质量经理应保持对调查报告和记录工作的检查和度量，发现调查工作的薄弱环节和调查结果的矛盾描述，进行多方的沟通交流，减少调查人员主观意见对调查结果的影响。

在产品策划阶段，质量经理应仔细阅读产品策划报告，发现策划报告本身考虑的欠缺以及和调查结果的差异程度，向决策领导提供产品策划质量检验报告。项目通过立项后，应建立项目产品的质量保证计划，包括：确定需要进行的评价，需要进行的审计和复审，项目可采用的标准，错误报告和跟踪过程，SQA小组自己应该提交的文档，为项目组应该提交的反馈数量等。

在产品需求分析阶段，质量经理应亲自或指导测试员（开发阶段的质检员）跟踪产品经理和开发经理分析讨论过程，理解分析思路，检查需求规格说明书的规范性和一致性，发现、记录漏洞和冲突。主持需求规格说明书和产品开发计划的审计和复审，保证项目计划与公司政策、内部软件标准和外界标准以及其他文档内容相符，该出需求分析质量审计报告。

在系统分析阶段、设计、模块开发阶段，质量经理应亲自或指导测试员识别、记录和跟踪原定计划与实际过程的偏差，帮助收集和分析软件度量信息，并对是否已经改正进行核实。

在系统测试阶段，质量经理应亲自或指导测试员对提交的产品部分或整体进行测试和审计，核实其是否符合原先定义好的部分的特性要求，识别、记录和跟踪出现的偏差，将发现的偏差缺陷及时反馈给开发经理，并对是否已经改正进行核实。

在产品包装阶段，质量经理应该亲自或指导质检员对产品的操作手册、技术说明书、教学演示程序、FAQ、产品宣传资料、产品包装形象设计等与实现的产品进行对照检查、并对相关必须执行过程（如病毒检测）进行监督，识别、记录和跟踪出现的偏差，将发现的偏差缺陷及时反馈给产品经理，并对是否已经改正进行核实。对于质量检验合格产品，签发产品质量合格证书。

在产品推广销售和用户使用阶段，质量经理应监督市场营销人员的工作程序和工作记录，检查是否符合公司制定的营销活动规范，检查产品资源（FAQ、手册、在线帮助等）是否得到充分利用，对资源改进维护提出意见并跟踪到实施改进。协助分析客户试用反馈的质量问题，并追踪开发部门落实改进。

总之，质量保证部将顺利开展一系列质量保证中的计划、监督、记录、分析和报告的活动，保证软件缺陷在其产生之后就立即被发现和鉴定，并尽快得到修复。

推荐到鲜果： 查阅更多相关主题的帖子: 研发组织 开发流程与制度 CMM