软件质量保证计划的实施
软件质量保证（即SQA——Software Quality Assurance），是CMM2级中的一个关键过程域,它是贯穿整个软件过程的第三方独立审查活动，出现在大多数关键过程域的检查与验证的公共特性中，在整个软件开发过程中充当重要角色。
从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在处理这些事物的时候要耐心细致。
1
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要对项目过程中的配置管理工作是否按照项目最初制定的配置管理计划进行监督，包括配置管理人员是否定期进行该方面的工作、是否所有人 2
得到的都是开发过程产品的有效版本。这里的过程产品包括项目过程中产生的代码和文档。
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人员就会真正从中体会到它的好处。
3
有效的软件质量管理
一、引言
随着社会信息化水平的不断提高，信息行业急速膨胀，信息企业快速成长，随之带来的信息市场竞争激烈，企业为了求生存，满足客户要求则成为各行各业的首要责任。依赖于质量、成本和进度的客户满意度，质量则是重点支撑之一，这样要求我们对质量管理需要加强认识。我们都知道pmbok把项目管理划分为9个知识领域，即范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、采购管理、风险管理和综合管理。质量管理作为9大知识领域之一，可见其重要性。
质量管理包括：质量计划编制、质量保证和质量控制三个过程域。质量计划是质量管理的第一过程域，它主要结合各个公司的质量方针，产品描述以及质量标准和规则通过收益、成本分析和流程设计等工具制定出来实施方略，其内容全面反应用户的要求，为质量小组成员有效工作提供了指南，为项目小组成员以及项目相关人员了解在项目进行中如何实施质量保证和控制提供依据，为确保项目质量得到保障提供坚实的基础。质量保证则是贯穿整个项目全生命周期的有计划和有系统的活动，经常性地针对整个项目质量计划的执行情况进行评估、检查与改进等工作，向管理者、顾客或其他方提供信任，确保项目质量与计划保持一致。质量控制是对阶段性的成果进行检测、验证，为质量保证提供参考依据，它是一个PDCA循环过程。
二 质量管理责任分配
我们公司在开发项目上按照规范化软件的生产方式进行生产，在生产流程上采用ISO9000的标准进行。每个项目除配备了项目开发所需角色外，还专门配备了配置管理小组、测试小组和质量保证小组确保质量管理的实施，下面针对这三种角色进行说明：
1、配置管理小组职责
配置管理小组是保证项目开发完毕的同时，内部文档和外部文档都同时完成。内部文档的及时产生和规范，是保证项目开发各小组能够更好的接口和沟通的重要前提，从另一个方面讲，也是保证工程不被某个关键路径所阻塞而延滞的前提。如上所述，配置管理小组还是保证质量保证小组得以发挥作用的基础。配置管理小组的主要职责包括： 完善各个部门发送需要存档和进行版本控制的代码、文档（包括外来文件）和阶段性成果； 对代码、文档等进行单向出入的控制； 对所有存档的文档进行版本控制； 提供文档规范，并传达到开发组中。
2、测试小组职责
测试小组作为质量控制的主要手段，负责软件的测试设计和执行工作。如同软件开发一样，测试在执行之前，同样需要进行测试计划和测试策略的设计，通常情况下测试可以分为如下几种类型，如：正确性测试、功能性测试、性能测试、安全测试和系统测试等。而这些测试均需要在测试计划和测试策略中进行描述用以指导测试小组成员进行测试用例编写和测试执行。程序员在交给测试人员之前是进行过一定的单元测试，确保程序编译、运行正确。
测试人员根据详细设计的文档对软件要实现的功能进行一一测试，保证软件的执行正确的实现设计要
求，在此也只证明了软件正确的反映了设计思想，但是否真正反映了用户的需求仍需要进一步的功能性测试。 测试人员只有根据软件需求规格说明书所提及的功能进行检测，才能确保项目组开发的软件产品满足用户需求。在正确性测试完成之后，需要测试的是软件的性能，软件的性能在本项目中占有重要的地位，性能要求有可能改变软件的设计，为避免造成软件的后期返工，测试在性能上需要较大的侧重。如果有必要的话，测试小组还需要做安全测试，以确保系统使用安全可靠。
4
3、质量保证小组职责
质量保证小组作为质量保证的实施小组，主要职责是保证软件透明开发的主要环节。在项目开发的过程中几乎所有的部门都与质量保证小组有关。质量保证小组对项目经理提供项目进度与项目真正开发时的差异报告，提出差异原因和改进方法。
在项目进度被延滞或质量保证小组认为某阶段开发质量有问题时，提请项目经理、项目负责
人等必要的相关人员举行质量会议。解决当前存在的和潜在的问题。质量保证是建立在文档
的复审基础之上，因而文档版本的控制，特别是软件配置管理，直接影响软件质量保证的影
响力和力度。质量保证小组的检测范围包括：系统分析人员是否正确的反映了用户的需求；
软件执行体是否正确的实现了分析人员的设计思想； 测试人员是否进行了较为彻底的和全
面的测试； 配置管理员是否对文档的规范化进行的比较彻底，版本控制是否有效。
三 质量管理实施
有了良好的资源配备，又如何在项目全生命周期内实施质量保证，让我们从以下几个方面来
看质量保证的实施过程：
1、项目进度的质量保证
项目进度是项目进行是否顺利的最直观表现。显然在项目开始之前，项目开发计划是必须的。
如果项目开发计划的制定的是完全合理的，那项目进度也就真正表达了项目与最终的交付使
用之间的距离，然而要制定完全合理的项目开发计划几乎不太可能。可见要保证项目进度，
首先要保证项目开发计划尽可能合理。
项目计划的合理程度与项目计划制定者从事类似规模和类似业务的项目的经验有直接关系，
通过经验往往能够预见潜在的阻碍，这样要求项目计划制定者需要集众人之力来完善计划。
当项目计划制定初期，由质量保证小组组织召开的项目计划评审会，邀请公司技术专家、用
户以及项目组小组成员一起讨论项目计划的可行性，会议通常采用头脑风暴法，各抒己见，
会后由指定的记录员形成质量记录，发送给相关人员，对其计划中不合理的地方进行修改完
善，并由质量保证人员对其结果跟踪，以确保项目计划完整性、可行性，完善后的计划交由
配置管理人员进行版本控制。
然而在计划实施过程中，计划不是“固定化”。常有人道，“计划赶不上变化”，但“要跟
上变化”。项目计划以里程碑为界限，将整个开发周期划分为若干阶段。根据里程碑的完成
情况，适当的调整每一个较小的阶段的任务量和完成的任务时间，这种方式非常有利于整个
项目计划的动态调整。也利于项目质量保证的实施。
实际运作中，当质保小组发现计划实施的差异后，报告项目经理，由项目经理组织负责对计
划进行周期性维护，对于已经变动的计划由质保小组协助配置管理小组完成版本控制。本公
司已经开发湖南移动的集中客服系统，开发中的子项目多达六个，历时十个月，目前多数项
目已经开发完毕，系统正在试运行阶段，项目金额数千万元。在这样的项目中，从管理者到
开发人员到测试人员都积累了较为丰富的经验，特别是项目开发计划的制定，和项目进度的
控制。
2、项目开发各阶段的质量保证
a、需求分析
5
需求分析是开发人员对系统需要做什么和如何做的定义过程。从系统分析的经验来看，这个过程往往是个循序渐进的过程，一次性对系统形成完整的认识是困难的。只有不断地和客户领域专家进行交流确认，方能逐步明了用户的需求。从系统开发的过程得知，系统分析时犯下的错误，会在接下来的阶段被成倍的放大，越是在开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工期和系统的质量。
解决系统分析错误的方法我们公司通常采用邀请用户参与进行需求评定，然后对其用户的意见由质保成员跟踪检测是否纳入需求规格说明书，同时与用户签字确认形成需求基线，交由配置管理员放入配置管理库。
虽然尽早的邀请用户参与，仍然避免不了项目进行中用户的需求变更请求。对于开发过程存在的需求变动，我们要求用户填写变更申请单发送给项目配置管理员，在通过配置配置员转交质保小组，负责组织专家小组和项目组成员一起讨论实施变更的可行性及实施后所带来的影响，小的变更则直接记录入变更记录原因分析项和风险项栏，大的变更则需要形成正式的变更报告，无论那种变更都需要对相应的文档实施同步变更（包括需求规格说明书、详细设计文、安装手册、操作手册等）。但是对于无法实现或是变更会带来巨大的影响而将导致进度的延期，这时，我们将变更报告提交给用户或邀请用户进行协调会议，讨论变更取舍问题或是项目进度变更问题。
决定变更之后，由项目经理组织实施变更，测试人员检测变更结果，而质保小组成员监督变更实施过程并协助配置管理员对变更后的成果物进行版本控制。变更实施完后，上线前还需要指定人员协助用户一同测试并由用户签字后同意方可上线。
b、系统设计
优良的体系结构应当具备可扩展性和可配置性，而好的体系结构则需要好的设计方法，自然设计选型成为了系统设计首要的工作，究竟是采用哪种设计方法好呢？
对于设计选型不能一概而论，需要针对项目的结构、项目的特征和用户的需求来分析，同样也要考虑到参与项目小组成员的素质，如果其中大部分都没有从事过面向对象的设计且项目进对紧迫，这样没有多余的时间来培训小组成员来掌握面向对象的设计方法，尽管众所周知面向对象设计方法的优势，我们还是不如采用面向过程的方式（除用户指定开发设计方式外）可以减少项目承担的技术风险。
我们公司有过一个项目，用户指定需要采用面向对象分析、设计和开发，且开发周期短，在无赖的情况下，项目小组只能选用面向对象的软件开发过程，由于项目小组很少从事过面向对象的开发，经验缺乏，导致项目上马后项目进度延误，项目没有达到预期的效果。
针对此次开发，我们分析其原因，发现小组成员在开发过程中对于新技术互相交流少，各自有各自的理解和想法，造成理解上的不一致性，导致工作重复性高，滞后项目进度。建议解决方法是项目组成员采用集中办公，分块学习，学习的成果马上向项目相关人员发布，再由配置管理员对其发布的文档进行整理、规类放入配置库以供大家共享。这样方便大家的互相学习，减少重复的工作。在这次开发中我们公司从管理人员、设计人员到开发人员都汲取了很多教训，同时经过此次项目的开发，小组成员也积累了丰富的面向对象的开发经验。 除设计选型，还有一个容易被忽视的问题，就是公共类开发。公共类开发可以减少工作中的 6
重复工作，降低开发成本。这要求我们再设计阶段通过对用户需求的仔细研究，尽可能的识别出公共类，并进行定义指定专人负责设计通知其它设计人员，以减少重复工作。对于项目组提供的设计文档，由质保小组组织技术专家、项目组设计人员、开发人员和测试人员对其设计文档的评审，检测设计文档对其下一阶段工作的可行性，及时发现设计中可能存在的错误，降低项目开发风险，同时确保设计文档能为开发人员、测试人员提供切实的指导。对于可复用的设计进行提取作为公共库设计和开发，提供项目组或整个公司重用。最后交由配置管理员进行设计文档的版本控制。
c、实现
实现也就是代码的生产过程。这里不仅包括代码的产生，同时也包括测试用例的产生。针对上一阶段提供详细设计，程序员开始编码并且调试程序，测试人员则根据设计进行测试用例的设计，设计出来的用例需要得到项目组成员认可由项目经理审核通过才能进入配置库。同时程序员调试完程序提交测试人员进行程序正确性检测。
d、文档管理
文档维护主要是配置管理小组的工作。文档从用途上分主要分为内部文档和外部文档。 内部文档包括： 项目开发计划； 需求分析； 体系结构设计说明； 详细设计说明； 构件索引； 构件成分说明； 构件接口及调用说明； 组件索引； 组件接口及调用说明； 类索引； 类属性及方法说明； 测试报告； 测试统计报告； 质量监督报告； 源代码； 文档分类版本索引； 软件安装打包文件。
外部文档主要包括： 软件安装手册； 软件操作手册； 在线帮助； 系统性能指标报告； 系统操作索引。
如何保证文档的全面性，使其真正为项目的进度提供保证，又不因为文档的写作而耽误项目的进度，这仍然是一个比较难解决的问题。解决此问题，其核心仍然是个"度"的问题。在本项目的开发中，配置管理小组的一个非常重要的任务还是书写文档规范和文档模板。当有文档模板后需要书写文档的人员只剩下"填空"的工作，从某种意义上讲，书写文档的速度会加快。如果书写文档的人员认为文档的更细致的部分可以由他人帮助完成，则该文档即交由他人完成，但此时文档并不算被正式提交，当他人书写完毕之后，必须由文档的初写者进行复审，复审通过后方可以正式提交，进入软件配置管理的循环中。
配置管理小组真正核心的工作是对文档的组织管理。根据文档的不同，文档的来源也不同，有些是通过质量保证小组经过复审之后转交给配置管理小组，有些则会直接从文档的出处到达配置管理小组。文档的管理是一个非常烦琐的工作，但是长远来看它不仅使项目的开发对单个主要人员的依赖减少，从而减少人员流动给项目的带来的风险，更重要的是在项目进行到后百分之十的时候起到拉动项目的作用。
从以往做大项目的经验来看，写作文档在项目开发的早期可能会使项目的进度比起不写文档要稍慢，但随着项目的进展，各个部门需要配合越来越多，开发者越来越需要知道其他人员的开发思路和开发过程，才能使自己的开发向前推进。一个明显的例子就是系统整合，或者某些环节是建立在其他环节完成的基础之上时，就更显现出文档交流的准确性和高效性。
3、系统维护质量保证
7
在我们公司，维护小组的任务一方面是保证对项目客户的跟踪服务，另一方面是确保该项目其它的开发人员从项目中尽快的解脱出来以便投入到下一个项目的开发中。所以通常项目维护小组成员主要由项目组的少部分开发人员承担完成。他们不仅了解软件的核心内容，而且与客户也不陌生，以便能够以最快的速度修正错误。对于一般性的错误，如操作不当等引起的问题，全部由维护小组执行完成，但需要用户测试确认上线。如果较大的修改则需要走变更控制流程，用户或者维护人员填写变更申请，经专家会议讨论分析可行方案在由维护小组实施，通过测试后方可提交用户。
维护小组的人员基本上是按项目跟进的。当一个项目刚刚交付用户时，在维护小组有较多的人员进行跟进，随软件的稳定，跟进的人逐步减少，并转移到其它项目中去。
质量保证是在项目实施过程中，定期评价项目绩效，以树立项目质量满足相关标准的信息。质量保证包括面向客户的质量保证和面向内部高层的质量保证。面向客户的质量保证是让客户相信项目正在向客户所期望的方向进行，正在越来越逼近目标;面向内部高层的质量保证是使高层认同项目组的工作，这些工作正是项目所需要的。
我们通过与质量控制部(公共部门)合作一起对项目实施质量保证，主要从软件产品和项目管理过程两个方面进行。
§1 项目管理过程质量保证
项目管理过程质量保证通过建立项目过程执行规范和定期、不定期比对、跟踪和反馈实现。
一、 项目过程规划和SQA计划制定
在项目启动后，项目经理和质量控制部QA一道对项目过程进行裁剪，通过综合考虑项目规模、重要性、周期等多个因素，共同确定项目必须执行的过程、可裁剪的过程以及可选的过程等，确立项目的过程规范。项目过程规范报高层审批后，由项目经理组织项目组成员进行培训，建立项目团队对过程的认识，特别明确项目中必须遵守的过程以及质量控制部制定的审计计划、审计措施等。客户方面，由项目经理与QA一起走访客户，说明公司的质量保证措施以及项目组准备采用的做法，同时接受客户提出的合理建议，融合到项目过程规范中，从而在一开始就建立客户对项目的信心。
质量控制部根据项目整体计划和迭代计划，制定相应的SQA计划，审计的时机是每次迭代和里程碑完成时。SQA计划是面向项目产出物制定，项目处于什么阶段，就会产出相应的可产出物。在实际操作中，我们把项目分为启动、执行、验收和关闭四个阶段，其中执行阶段的每一个迭代过程又分为需求开发、代码实现、测试验收和上线运行四个子阶段，对于每 8
个阶段均定义了主要的产出文档，如需求规格说明书、系统设计说明书、测试用例、系统测试报告、用户验收测试报告、试运行报告等。
二、 项目过程审计
在项目实施过程中，质量控制部根据SQA计划对项目过程进行审计，一方面检查相应的产出物是否已产生，另一方面是检查产出物的形式是否符合规范、内容是否完整、是否位于配置管理系统中的合适目录下等。每次审计完成后，编写SQA报告发送给项目经理和公司高层，说明项目目前的状态、整改情况、本次审计新发现的问题以及对项目未来的预测等。SQA审计报告经高层审批并去掉公司内部使用的信息后，抄送给客户。
三、 问题监控和跟踪
项目经理根据SQA审计报告中提出的问题，与SQA一起分析讨论不符合过程规范的原因，确定问题是因为人为疏忽、意识缺失、没有时间还是其他原因造成的。针对每一种原因，制定下一步的培训和整改计划，力求不再重复犯错。同时，由项目经理和QA与客户沟通，就SQA报告说明项目的进展情况、出现的问题和改进措施，减少客户的担心，增强客户的信息。
通过上述PDCA的过程，从而确保项目组在既定的路线上行进，在做着正确的事情。 §2 软件产品质量保证
软件产品质量保证主要通过文档评审、技术评审、代码走查和测试检查实现。
一、 文档评审
实施过程前期产生的需求规格说明书、系统设计说明书、测试用例等文档是后期编码、测试的主要依据和输入，这些文档的质量直接决定了软件系统的好坏、系统返工的多寡以及客户满意度。因而对这些文档的评审尤为重要，评审的目的在于在交付给下游开发或测试时及早发现问题，修正错误，以免问题和错误在系统中的蔓。
文档评审采用同行评审会议的方式进行，由项目经理组织，开发相关文档参与的角色包括其他子系统的系统分析员、质量控制部相关人员、其他兄弟部门有类似经验的系统分析员等;测试相关文档则由项目经理、测试经理、系统分析员和其他测试人员参与。评审过程中，主要从以下几方面考察文档的质量：
? 可读性。主要从文档是否符合公司模板规范、逻辑结构层次是否清晰明确、文字表达是否无歧义等方面判断;
? 完整性。主要从文档是否完全满足要求，是否已覆盖所有的功能点等方面判断; ? 一致性。主要判断文档表述是否前后不一、是否有矛盾等;
? 技术可行性。主要判断目前的技术框架是否支持，是否有类似的经验，是否有技术风险等。
二、 技术评审
9
技术评审包括项目技术框架的选型评审、具体某个模块的技术实现方式评审等。技术框架的评审目的是为了在进入大规模编码开发前确认选择何种技术框架、判断现有的技术框架是否满足项目功能和性能需求、框架是否足够稳定以及可能存在的风险等，具体某个模块的技术实现方式评审目的是为了保证选择的实现方式目前来说是最优的、可以推广到其他模块使用的。技术评审通过评审会议的方式进行，参与的人员包括项目经理、系统分析员、开发人员、公司内部相关技术的专家、有同类项目经验的实施人员、质量控制人员等。
三、 代码走查
代码走查主要是对软件代码进行复审，主要以高级程序员复审代码或同级别的程序员交叉检查的形式进行。代码走查的目的是通过抽查，保证代码的编写和注释符合编码规范，编码逻辑符合系统设计要求，减少测试返工以及因测试返工引起的来回沟通、回归测试等问题，降低管理成本，提高开发效率。
四、 测试检查
测试检查是由测试人员根据测试用例对软件产品进行功能测试以及使用压力测试工具对系统进行压力测试。测试检查的目的是确保交付给客户执行验收测试前软件产品经内部严格测试，检查系统是否满足用户需求和符合实际应用环境的需要，从而增强客户对项目成功的信心。
测试发现的缺陷我们使用JIRA系统进行跟踪和监控。测试人员在系统上提bug，由相应的系统分析员负责对缺陷进行原因分析和影响分析，必要时与程序员一起确认问题产生的原因和可能影响的模块，分析后转交由相应的开发人员进行修改，缺陷修复并经单元测试后发布到测试环境交由测试人员进行验证测试并关闭此问题，最后由客户进行验收测试后并确定发布版本和发布时间后予以发布。在这个流程中，测试人员验证测试时需要对该缺陷涉及的本模块其他功能和其他模块进行一轮回归测试，确保已修复的缺陷不再重复产生，其他功能不受影响。
另外，为了确保已发现的缺陷不再重复出现，对于频繁出现的，如界面显示的是代码而非中文、缺乏信息提示、没有进行逻辑检查、后台计算结果有误等缺陷进行进一步的分析，找出是因为系统设计文档的缺陷、人为疏忽还是没有按照设计文档设计或其他原因所导致，从而制定相应的改进措施。
一、使用完善的评估方法的重要性
一般情况下，软件项目会受到四种因素的控制，它们分别是时间、需求、资源（包括人员、硬件条件以及资金）和风险。这些因素的任何意料之外的变化都会对我们的项目产生影响。
因此，做好时间和项目资源需求的评估是非常必要的。如果过低估计项目预算，会由于缺乏项目实施时间、资金、硬件条件或是没 有足够的人来完成等原因导致非常严重的后果。但如果过高地估计项目需求预算，也会因为成本太高使企业付出很大的代价， 10
最后这个项目可能会被搁浅，就算项目被批准实施，也会由于此项目占用大量的资源而使其它的项目由于得不到足够的资源来呈现"饥饿"状态。从我的经验来看，对一个项目做时间和所需资源的预算评估通常对于大多数团队和项目经理是一个非常大的挑战。形成挑战的原因有很多，如它们对预算评估没有足够的经验、对评估技术或所涉及的商业领域缺乏了解，需求不清楚等。尽管负责项目预算评估的经理已经尝试了使用最好的方法来处理需求及各方的关系问题，但由于以上的原因，不可避免地导至整个团队由于评估失误而超过预算，或是项目失败。还有另外一种评估预算的方法，就是使用高度乐观的方法进行评估，而忽略我们需要处理的具体项目。那么我们到底该怎么做呢？
二、实用的预算评估技术
在我们开始研究预算评估之前，需要对我们能提供的预算评估类型有一个初步的认识。预算评估可以被简单地分为下面三种类型：
1. 宏观预算评估：这种评估方式将根据项目的宏观轮廓进行一个总体的估计。这种估计是非常粗略的。在理想状态下，所评估出来的值应该是实际值的两倍至三倍。
2. 粗略预算评估：用这种评估方式评估出来的数据已经非常接近实际值了。在理想状态下，评估出来的值应该是实际值的50%至100%。
3. 精确预算评估：这是一种非常好的预算评估主要。在理想状态下，所评估出来的值应该是实际值的25%至50%。
决定使用这三种不同预算评估类型中的哪一种是十分重要的。当我们对需要做的项目背景和业务非常熟悉，并且类似的项目已经做过很多次的情况下，使用精确评估是可行的。当我们正在做系统维护工作时，所能遇到的问题是已知的，或是增加一个我们曾经做过的功能时，这种预算评估是允许的。粗略评估是在我们对需求比较熟悉的，以及对相关领域和技术熟悉的情况下采用的。而在所有其他的情况下，最好的预算评估方法就是宏观预算评估。也许有很多人固执地认为宏观预算评估的结果几乎等于没做任何评估！但这种评估的结果实际上是非常价值的，因为这些评估结果可以给企业和项目街头团队一些关于正在进行的项目需要些什么，其中包括时间、资源和资金。使用这种方法我们至少知道某个项目需要两到六个月的时间来完成。如果不进行评估，也许我们根据就不知道项目需要多少时间来完成。根据评估结果，我们可以根据需要对某些重要的项目进行更细致的预算评估。例如，我们可以为我们需要的基础构架提供一个精略评估，而不仅仅是一个关于人员和时间的宏观预算评估结果。三、如何进行宏观预算评估
我公司今年在软件项目开发上，提出要以“预算”为核心的预算体制，希望能通过预算制对项目进行成本控制和项目管理。但在执行过程中，出现各种矛盾和问题，导致预算实施起来非常不宜操作。
1、软件项目预算要作到什么程度，才算是一个合格的预算？
2、由于做预算，需要对项目进行深入分析，作出工作量核算，需要投入人员与时间，那么作预算书是不是要有预算？
11
3、预算在软件项目开发和项目管理中应该是什么样的流程？怎样才能做好预算？ 对软件项目的费用预算，主要从以下几个方面着想：
1、工作场所使用的预算，包括自建场所和租用场所2种。
2、硬件费用，对纯软件项目，主要是PC机，工作站，服务器等。
3、软件费用， 包括操作系统(如NT)，办公软件(如LOTUS NOTES)，软件开发软件(如NT，ORBIX开发LICENSE，VC++等)。
4、软件开发人员报酬，即开发人员工资，奖金，等。
5、软件开发人员出差费用，如外出调研，参加研讨会，等。
以上因素的1，4实际上都是由软件项目的规模和开发周期决定的。如何预测软件规模，在CMM中有几种比较流行的预测方法，如WIDEBAND DELPHI，COCOMO。
这里以WIDEBAND DELPHI为例简单介绍软件规模预测(详细流程可以参考相关软件项目管理材料)：
1、将软件项目根据概要需求分割成功能点(FUNCTION POINT)，越细越好。
2、由至少3名领域专家对每个功能点进行逻辑代码行预测。针对每个功能点可进行多轮预测直到大家的结果的误差不超过20%。
3、总结所有的预测结果，得到此项目的逻辑代码量。
4、根据业界人均日代码量(指整个生命周期，非只编码阶段)经验值或本公司对相关项目的经验值，以及在各个软件开发阶段(指需求分析，设计，编码，测试等)工作量的百分比分布，以及每月的工作日，就知道需要多少人月来开发这个项目。
5、然后在根据市场需求时间，项目的人员到位情况，就能定出项目计划和进度表(包括项目起始结束时间，每个阶段的进度安排，每个月的投入人员，等等)。
6、这样，以上的1和4的费用预测就出来了。
至于其它因素，要看项目的具体情况而定，不难得到。软件项目预算要做到什么程度，要看实际情况。严格来讲，在项目实施过程中所要涉及的人、财、物都要折算成现金表现方式，明确表示出要多少人、多少物资花多少时间，才能完成此项目。并且最重要的是，所有人、财、物最后的表现方式均为多少钱。 但是这种方法本身实施起来就要消耗一定的资源，如果公司内部已有一个统一完善的资源数据库，实施比较容易。但如你所说，你们公司刚刚开始实行预算制，恐怕是没有这样的数据库的。如果为一个小项目大动干戈，就有点得不偿失了。因此，实际上，在制定预算当中所消耗的资源，也是要纳入考虑的，虽然这些并不表现在项目预算表上。 对于大型项目，只有通过预算，才能合理分派资源，并避免在项目实施过程中失控。因此，对于大型项目而言，预算还是非常非常重要的。 软件项目与任何工程性的项目一样，需要按项目管理的基本原理进行项目预算。项目预算本身并不是目的，也不是说凡是按项目预算进行就好。项目预算只是为建立目标管理等科学的管理体系提供依据，应该了解一点项目预算不是从天而降，需要不断总结才能使预算日趋准确，其基础工作时进行作业分析，记录以往系统的开发过程，只有在不断总结的基础上才能作好项目预算。
对于一个软件项目的开发来讲，做好项目计划书是非常必要的。这里面包括对人力、财力、 12
时间（进度）以及质量的控制。贵公司在实行预算管理的时候，应该注意分析一个项目所需人力、财力和时间（进度）的所有信息，在这基础之上，方能测算整个项目的成本以及今后的收益！对于做预算书要不要有预算(可能更多的是财务预算），我的建议：凡是要发生费用的，都应该做预算！
根据公司规模的大小、相关制度体系的严密性、项目的复杂程度来决定预算到什么样的程度。如果公司其他制度都非常严格，并且员工已经具有高效完成工作的习惯，则预算可以非常详细。相反，如果公司的工作一直是走到哪再看一看，那么，一个简单的预算已经足够
质量成本，是指企业为保证产品质量而支出的一切费用以及由于产品质量未达到既定的标准而造成的一切损失。加强企业质量成本管理，一方面有利于企业提高产品质量，降低经营成本；另一方面也有利于增强企业产品价格竞争力，提高企业盈利能力和盈利水平。
质量成本管理，重在方法管理。企业如采用一套行之有效的科学管理方法，将使企业管理成本更低，成效更为明显，达到事半功倍的效果。经过多年的实践总结和理论研究，笔者认为，企业实施质量成本管理应高度重视以下八项工作。
分析企业质量成本构成情况
质量成本包括直接质量成本和间接质量成本。直接质量成本是指在产品的制造和销售过程中所发生的质量成本，一般由内部故障成本、外部故障成本、鉴定成本和预防成本四个部分组成。内部故障成本是指企业内部由于生产的产品质量有缺陷而造成的损失和为处理质量缺陷而发生的费用的总和，一般包括废品损失、返工费用、复检费用、停工损失以及不合格品处理费用等。外部故障成本是指在销售和使用中发现产品缺陷而产生的由制造企业支付的一切费用的总和，它同内部故障成本的区别在于不合格品是在发运给顾客后才发现的，一般包括保修费、索赔费、诉讼费、退货费、降价费。鉴定成本是指在“一次交验合格”的情况下，为检验产品质量而发生的一切费用，一般包括进货测试费、工序和成品检验费、在库物资复检费、对测试设备的评价费、质量评审费。预防成本是指为了防止质量缺陷发生，保证产品质量，使故障成本和鉴定成本最低而耗费的费用，一般包括质量计划编制费、质量管理培训教育费、工序控制费、产品评审费、质量信息费、质量管理实施费。间接质量成本是指 在直接质量成本的基础上进一步引伸和扩展的成本，它涉及到制造和销售过程以外的质量成本，一般包括：无形质量成本、使用质量成本、供应商质量成本、设备质量成本。
分析企业质量成本的构成，有利于企业明确质量成本可能发生的环节，建立必要的质量成本控制措施。一些企业建立了质量成本会计分录，分门别类地统计并核算各质量成本项目，以此发现质量成本发生的环节、发生的多少、发生的原因，为企业落实质量责任、采取质量措施，提供详实的资料。
建立企业质量成本控制标准
为加强质量成本管理工作，企业可设立质量成本管理中心，制定质量成本管理制度，建立质量成本控制标准。例如，中国一汽集团四川专业汽车厂建立了企业质量成本控制标准，标准规定质量成本占销售额的比例不得超过10％。其中：内部故障成本占全部质量成本的 13
比例范围应在25％～40％；外部故障成本占全部质量成本的比例范围应在20％～40％；鉴定成本占全都质量成本的比例范围应在10％～50％：预防成本占全部质量成本的比例范围应在0.5％～5％。企业规定，如突破上述规定标准，质量成本管理中心将责成有关部门分析原因，采取有效措施。
建立质量成本目标体系
质量目标是指企业在一定时期内在质量方面所要达到的预期成果。开展质量成本控制工作，应有明确的控制目标，这是企业质量成本控制工作的基础。
建立质量成本控制目标，应注重以下几点：一是目标要有突破性。所谓突破性，就是要在现有的质量成本基础上有所突破，成本总量要有一定幅度的降低；二是目标要有控制性。所谓控制性，就是为把质量水平和质量指标维持在一定的水平上而制定的目标。这样的目标通常成为日常控制工作的标准；三是目标要有可实现性。所谓可实现性，就是通过全体员工的努力，目标是可以实现的。切不可把目标定得过高，让人觉得高不可攀，难以实现，丧失信心；四是目标应力求量化。尽量避免使用一些不确定语言，多用数字表述目标，让人一目了然，便于操作和验证。
建立质量控制目标，既要有总目标，也要有分目标。总目标规定企业质量成本总体控制水平，在一定时间内应达到的成果或要求。将总目标进行分解，就成为一系列分目标，这些分目标由相应的职能部门来完成。如将总目标分解成：采购成本控制目标，财务成本控制目标，制造费用控制目标，销售费用控制目标等分目标，分别由相应的职能部门来完成。每一项分目标，还可进一步分解成一系列子目标，如采购成本控制分目标可分解成：原材料采购成本控制目标、外协件采购成本控制目标、低质易耗品采购成本控制目标等子目标。 做好质量成本控制计划
质量成本控制目标能否顺利实现，关键在于企业的质量成本控制计划制定得是否完善、合理。质量成本控制计划，应当规定目标体系中的每一个目标该由谁来完成，什么时候完成，如何检验评价这些目标；应将目标体系落实到各部门、各人，落实到每季度、每月甚至每周，将目标按人按时间进行分摊。这样，通过每一个人，每一个部门，每一段时间的工作，实现其预期的分目标，从而保障企业总目标的实现。
企业质量成本管理中心是质量成本控制计划编制、修订和实施的职能部门。计划编制时，应多召开各种形式的座谈会，征求各部门对质量计划草案的意见，多次反复修改，便于以后计划的实施。
建立质量成本“三全”控制体系
质量成本控制，涉及到企业的每一个员工、每一个部门、每一个工作环节。因此，企业质量管理部门能否通过宣传、通过制度，动员全体员工参与，进行全过程的质量控制，开展全企业质量管理，关系到企业质量成本计划能否顺利实施。
1、全员控制。如何才能调动全体员工积极性和创造性，共同做好质量成本控制工作呢?我们以为，企业应从以下几个方面着手：一是抓好全员质量宣教工作，加强员工质量成本控制意识，促使员工积极参加各项质量活动；二是通过建立质量责任制，明确责任和权限，各司其职，互相配合，建立企业高效、协调、有序的质量保障体系；三是开展多种形式的群众 14
性质量活动，如质量控制小组，充分发挥广大职工的聪明才智。
2、全过程控制。质量成本发生在各个部门、各个环节，发生在每一个人、每一天的工作中。因此，质量成本控制，要全员参与，也要全过程控制。全过程控制，应对每一过程制定严格的操作规范、控制标准、检测手段，使每一位员工知道如何降低损耗、减少浪费、控制过程成本；全过程控制，应坚持预防为主，把不合格品消灭在它的形成过程之中，做到防患于未然；全过程控制，应充分发挥检验的作用，做好检验标准制定、检测手段制定、检测方法制定工作，做好产品的首检、巡检、专检工作，尽量减少成批报废，提前预报质量情况。
3、全企业控制。在全企业质量成本控制方面，我们认为，成本控制涉及到企业高层、中层、基层工作，每个层次。
15