质保方案.docx

质保方案.docx

《质保方案.docx》由会员分享，可在线阅读，更多相关《质保方案.docx（9页珍藏版）》请在冰豆网上搜索。

质保方案

XXX项目

开发质量保证方案

编制：

生效日期：

审核：

批准：

----------------------------------------------------------------------------------------------------------

XXXXX有限公司对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。

文件更改摘要：

日期

版本号

修订说明

修订人

审核人

批准人

1

方案概括

本方案的目的在于对XXXX开发的各种必要的质量保证措施，以保证所交付的开发模块能够满足项目预定需求，能够满足本项目总体制定的且经评审批准的该软件系统需求规格说明书中规定的各项具体需求。

XXXX公司在开发XXXX中的各个功能模块（其中包括为本项目研发或选用的各种支持软件、组件）时，都应该执行本方案中的有关规定。

2软件质量管理 

2.1.1机构 

    在XXXX公司针对XXXX整个开发期间，必须成立软件质量管理小组负责质量保证工作，软件质量保证组和项目负责人及各领导组必须检查和督促本计划的实施。

系统的软件质量保证人员有权直接向各领导组报告该项目的各个功能模块的质量状况，XXXX的软件质量保证人员应该根据对项目的具体要求，制订必要的规程和规定，以确保完全遵守本方案的所有要求。

2.1.2任务 

    软件质量保证工作涉及软件生存周期各阶段的活动，应该贯彻到日常的开发活动中，而且应该特别注意XXXX开发模块的早期评审工作。

因此，对于所负责系统，要按照双方所约定的各项规定进行各项评审工作。

软件质量保证小组要参加所有的评审与检查活动，评审与检查的目的是为了确保在XXXX功能模块开发工作的各个阶段和各个方面都认真采取各项措施来保证与提高功能模块的质量。

在整个项目开发过程中，要进行如下几类评审与检查工作：

Ø阶段评审：

在XXXX开发过程中，要定期地或阶段性地对某一开发阶段或某几个开发阶段的阶段产品进行评审。

在XXXX开发及其所属各子功能模块的开发过程中，应该进行以下三次评审：

第一次评审软件需求、概要设计、验证与确认方法；第二次评审详细设计、功能测试与演示，并对第一次评审结果复核；第三次是功能检查、物理检查和综合检查。

    每一次评审工作都应填写评审总结报告（RSR）、评审问题记录（RPL）、评审成员签字表（RMT）与软件问题报告单（SPR）等四张表格。

Ø日常检查：

在XXXX的工程化开发过程中，各子模块应该填写进展报表，即进展报表表头、阶段进度表、阶段模块完成情况表、模块开发费用表等四张表格。

Ø软件验收：

必须组织专门的验收小组对XXXX相关模块及其所属各个子模块进行验收。

质量管理小组验收内容应包括文档验收、程序验收、演示、验收测试与测试结果等几项工作。

2.1.3职责分配

我公司在开发项目上按照规范化软件的生产方式进行生产。

每个项目除配备了项目开发所需角色外，还专门配备了质量保证小组、配置管理小组、测试小组来确保质量管理的实施，在XXXX的软件质量保证小组中，其各方面人员的职责如下

2.1.4质量保证小组职责

质量保证小组作为质量保证的实施小组，在项目开发的过程中几乎所有的部门都与质量保证小组有关。

质量保证小组的主要职责是：

以独立审查方式，从第三方的角度监控软件开发任务的执行，分析项目内存在的质量问题，审查项目的质量活动，给出质量审计报告。

就项目是否遵循已制定的计划、标准和规程，给开发人员和管理层提供反映产品和过程质量的信息和数据，使他们能了解整个项目生存周期中工作产品和过程的情况，提高项目透明度，从而支持其交付高质量的软件产品。

质量保证人员依据质量保证计划，通过质量审计报告向项目经理及有关人员提出已经识别出的不符合项，并跟踪不符合项的解决过程，通过审计周报或者审计月报向项目经理提供过程和产品质量数据，并与项目组协商不符合项的解决办法。

质量保证小组的检测范围主要包括：

项目的进度是否按照项目计划执行，用户需求是否得到了用户的签字确认，软件需求是否正确的反映了用户的需求，是否将每一项用户需求都映射到软件需求；系统设计是否完全反映了软件需求；实现的软件是否正确的体现了系统设计；测试人员是否进行了较为彻底的和全面的测试；客户验收和交接清单是否完备；对于系统运行中出现的问题，维护人员是否记录了详细的维护记录；配置管理员是否按照配置管理计划建立了基线，是否严格控制变更过程，是否对配置库进行了维护。

2.1.5配置管理小组职责

配置管理活动的目的是通过执行版本控制、变更控制、基线管理等规程，借助配置管理工具的使用，来保证整个生命周期过程产生的所有配置项的完整性、一致性和可追溯性。

配置管理是对工作成果（阶段工作成果和产品成果、进展状态成果）的一种有效保护形式，是反映项目及其工作产品的过去、现在、动态的资料和数据集中管理体现。

配置管理小组的主要职责包括：

根据项目计划制定配置管理计划，建立配置库，为项目组人员分配配置库权限，创建需求、设计、开发、测试、交付阶段的基线。

当纳入基线库的工作产品发生变更时，严格按照配置项变更控制过程执行变更，变更后建立新的基线。

2.1.6测试小组职责

作为质量控制的主要手段，如同软件开发一样，测试在执行之前，测试小组制定软件测试计划、测试用例的编写和执行工作。

本项目中，测试可以分为如下几种类型：

代码走查、单元测试、集成测试、系统测试。

为了保证程序的质量，开发人员需要对同伴的代码进行代码走查，同时对自己编写的程序进行单元测试，确保程序编译、运行正确。

测试人员根据软件需求分析报告进行软件集成测试用例和系统测试用例的编写。

对编写完成的测试用例提交项目组进行评审，同时质量保证人员对评审过程和工作产品进行监测。

测试人员根据测试计划和测试用例执行测试用例，并对发现的缺陷进行记录，只有这样才能确保项目组开发的软件产品满足用户需求。

在完成集成测试之后，可以进行软件系统测试，系统测试包括对软件进行功能测试、性能测试、安全测试、压力测试。

只有进行了系统测试软件测试才是完整的。

系统测试在本项目中占有重要的地位，性能要求有可能改变软件的设计，为避免造成软件的后期返工，测试在性能上需要较大的侧重。

2.2软件配置管理 

    对XXXX的各项配置进行及时、合理的管理，是确保模块质量的重要手段，也是确保该软件具有强大生命力的重要措施。

有关XXXX的配置管理工作，可按软件项目组编写的《软件配置管理计划》。

在软件配置管理工作中，要特别注意规定对软件问题报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的机构及其职责。

2.3媒体控制 

    为了保护计算机程序的物理媒体，以免非法存取、意外损坏或自然老化，XXXX的各个子功能模块（包括支持软件）都必须设立配置管理人员，并按照软件项目小组制订的、且经领导层批准的《软件配置管理计划》妥善管理和存放各个子模块及其专用支持模块的媒体。

2.4记录收集、维护和保存 

    在项目及其所属的各个子功能模块的研制与开发期间，要进行各种软件质量保证活动，准确记录、及时分析并妥善保存有关这些活动的记录，是确保软件质量的重要条件。

在软件质量保证小组中，应有专人负责收集、汇总与保存有关软件质量保证活动的记录。

3质量管理内容

3.1编制和评审质量计划

制定质量保证计划：

依据项目计划及项目质量目标确定需要检查的主要过程和工作产品，识别项目过程中的干系人及其活动，估计检查时间和人员，并制定出本项目的质量保证计划。

质量保证计划的主要内容包括：

例行审计和里程碑评审，需要监督的重要活动和工作产品，确定审计方式，根据项目计划中的评审计划确定质量保证人员需要参加的评审计划。

明确质量审计报告的报送范围。

质量保证计划的评审：

质量保证计划需要经过评审方能生效，以确保质量保证计划和项目计划的一致性。

经过批准的质量保证计划需要纳入配置管理。

当项目计划变更时，需要及时更改和复审质量保证计划。

3.2文档

3.2.1基本文档 

    为了确保XXXX所开发的实现满足认可的需求规格说明书中规定的各项需求，软件开发项目组至少应该编写以下八个方面内容的文档：

（一）软件需求规格说明书（SRS）;  

（二）软件设计说明书（SDD）;

（三）软件测试计划（STP）;

（四）软件测试报告（STR）;  

（五）用户手册（SUM）;

（六）源程序清单（SCL）;  

（七）项目实施计划（PIP）;  

（八）项目开发总结（PDS）

3.2.2其他文档 

    除了基本文档之外，对于尚在开发中的XXXX的其他功能模块，还应该包括以下四个方面的文档：

（一）软件质量保证计划（SQAP）;

（二）软件配置管理计划（SCMP）;  

（三）项目进展报表（PPR）;

（四）阶段评审报表（PRR）  

3.2.3文档质量的度量准则 

    文档是软件的重要组成部分，是软件生存周期各个不同阶段的产品描述。

验证和确认就是要检查各阶段文档的合适性。

评审文档质量的度量准则有以下六条：

（一）完备性：

所有承担软件开发任务的项目，都必须按照GB 8567（是国家标准局的指南文档，名称叫《计算机软件产品开发文件编制指南 》）的规定编制相应的文档，以保证在开发阶段结束时其文档是齐全的。

（二）正确性：

在软件开发各个阶段所编写的文档的内容，必须真实地反映该阶段的工作且与该阶段的需求相一致。

（三）简明性：

在软件开发各个阶段所编写的各种文档的语言表达应该清晰、准确简练，适合各种文档的特定读者。

（四）可追踪性：

 在软件开发各个阶段所编写的各种文档应该具有良好的可追踪性。

（五）自说明性：

在软件开发各个阶段所编写的各种文档应该具有较好的自说明性。

（六）规范性：

在软件开发各个阶段所编写的各种文档应该具有良好的规范性。

文档的规范性是指文档的封面、大纲、术语的含义以及图示符号等符合有关规范的规定。

3.3“过程和工作产品”的质量检查

根据质量保证计划进行质量的审计工作，并发布质量审计报告。

审计的主要内容包括：

是否按照过程要求执行了相应的活动，是否按照过程要求产生了相应的工作产品。

本项目中对质量的控制主要体现在不同阶段的审计当中。

3.4不符合项的跟踪处理

对审计中发现的不符合项，要求项目组及时处理，质量保证人员需要确认不符合项的状态，直到最终的不符合项状态为“完成”为止。

3.5质量保证措施

通过质量管理责任的分配，通过如下几个方面来进行质量保证的实施过程：

3.5.1项目进度

项目计划的制定为工程项目实施、管理和支持工作、项目进度、成本、质量及过程产品的有效控制打下了良好的基础，以便所有相关人员能够按照该计划有条不紊地开展工作；制定《项目计划》，必须获得相关干系人的认可，并以此作为项目跟踪的基础。

项目进度是项目进行是否顺利的最直观表现。

制定合理的项目计划首要前提是选择从事类似规模和类似业务项目的有经验的项目负责人参加制定项目进度计划。

项目计划由项目负责人制定，由项目各小组组长、项目成员、干系人、质量保证人员参加一起进行评审。

评审过程主要讨论项目计划的可行性，对其中不合理的地方提出修改意见，对计划中不合理的地方进行修改完善，并由质量保证人员对其结果进行跟踪处理，以确保项目计划完整性、可行性，项目计划评审通过后，交由配置管理人员进行配置管理。

在计划实施过程中，按项目计划中里程碑为界限，将整个开发周期划分为若干阶段。

根据里程碑的完成情况，适当的调整每一个较小的阶段的任务量和完成的任务时间，动态跟踪和动态调整，以利于项目质量保证的实施。

实际运作中，质量保证人员在对项目执行过程进行检查时，对于发现的项目偏差，以质量审计报告的形式提交项目负责人。

由项目负责人组织人员对计划进行维护，对于已经变动的项目计划，由配置管理进行配置管理。

3.5.2需求分析

需求分析是开发人员对系统需要做什么和如何做的定义过程。

从系统分析的经验来看，这个过程往往是个循序渐进的过程，一次性对系统形成完整的认识是困难的。

只有不断地和客户领域专家进行交流确认，方能逐步明了用户的需求。

从系统开发的过程得知，系统分析时犯下的错误，会在接下来的阶段被成倍的放大，越是在开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工期和系统的质量。

本项目中，将邀请招标方技术负责人参与需求调研，以便保证需求调研质量，同时形成用户需求说明书。

需求评审时会同双方管理层、项目实施层共同进行，对于通过用户确认的需求，交由配置管理员形成需求基线。

用户需求在招标方确认后，由系统分析人员形成软件需求分析报告，同时对软件需求分析报告进行评审，对于评审通过的软件需求分析报告可以交由测试人员进行测试计划和测试用例的编写。

对于开发过程存在的需求变动，招标方填写变更申请单发给项目经理，在质量保证人员参加的情况下，对这个变更进行评审，由项目经理组织项目组成员一起讨论实施变更的可行性及实施后所带来的影响，对于影响小的变更直接记录，大的变更则需要形成正式的变更报告，无论那种变更都需要对相应的文档实施同步变更（包括需求分析报告、系统设计、安装手册、操作手册等）。

但是对于无法实现或是变更会带来巨大的影响而将导致进度的延期，这时，我们将变更报告提交给招标方并召开协调会议，讨论变更取舍问题或是项目进度变更问题。

决定变更之后，由项目负责人组织实施变更，测试人员检测变更结果，而质量保证人员监督变更实施过程，并协助配置管理员对变更后的成果进行配置管理。

变更实施完后，运行前还需要协助用户一同测试并由招标方签字后同意方可上线。

3.5.3系统实现

系统实现的目的是依据系统设计文档，由程序员进行程序编写，以便实现设计要求，系统实现过程中，开发人员需要对模块进行代码走查和交叉单元测试，以保证模块代码质量。

软件实现也就是代码的生产过程。

根据上一阶段形成的设计文档，程序员在完成代码之后，可以开始编码并且进行代码走查和单元测试。

对于测试完成的程序可以交由配置管理人员进行配置管理。

3.5.4系统测试

系统开发涉及到一系列的过程，每一个过程都有可能引入缺陷（Bug），本系统质量的好坏直接关系到正常使用和日后的维护。

在开发过程中，我们将质量控制贯穿于所有阶段和所有参与系统的人员中，包括系统分析、设计和编码。

分阶段的评审和测试是软件质量的有力保障。

系统存在平台测试和应用系统的测试以及最终的测试。

由于测试也存在协调的问题，如错误具体定位，在应用系统发现一个错误，到底是应用系统的自身的错误还是中间件存在的错误，需要测试人员进行准确的判断。

3.6评审和检查 

    对新开发的或正在开发的XXXX各个功能模块，都要按照GB 8566（计算机软件开发规范）的规定认真进行定期的或阶段性的各项评审工作。

就整个XXXX模块开发过程而言，至少要进行模块需求评审、概要设计评审、详细设计评审、软件验证和确认评审、功能检查、物理检查、综合检查以及管理评审等八个方面的评审和检查工作。

在模块及其所属各个子模块的开发过程中，把前七种评审分成三次进行。

在每次评审之后，要对评审结果作出明确的管理决策。

下面给出每次评审应该进行的工作。

3.6.1第一次评审 

    第一次评审会对XXXX模块需求、概要设计以及验证与确认方法进行评审。

（一）XXXX模块需求评审（SRR）应确保在软件需求规格说明书中规定的各项需求的合理性。

（二）概要设计评审（PDR）应评价软件设计说明书中的软件概要设计的技术合理性。

（三）软件验证和确认评审（SV&VR）应评价软件验证和确认计划中确定的验证和确认方法的合适性与完整性。

3.6.2第二次评审 

    第二次评审会要对详细设计、功能测试与演示进行评审，并对第一次评审结果进行复核。

如果在软件开发过程中发现需要修改第一次评审结果，则应按照《软件配置管理计划》的规定处理。

（一）详细设计评审（DDR）应确定软件设计说明书中的详细设计在满足软件需求规格说明书中的需求方面的可接受性。

（二）编程格式评审应确保所有编码采用规定的工作语言，能在规定的运行环境中运行，并且符合GB 8566中提倡的编程风格。

在满足这些要求之后，方可进行测试工作。

3.6.3第三次评审 

    第三次评审会要进行功能检查、物理检查和综合检查。

这些评审会应在集成测试阶段结束后进行。

（一）功能检查（FA）应验证所开发的XXXX功能模块已经满足在软件需求规格说明书中规定的所有需求。

（二）物理检查（PA）应对XXXX功能模块进行物理检查，以验证程序和文档已经一致、并已做好了交付的准备。

（三）综合检查（CA）应验证代码和设计文档的一致性、接口规格说明之间的一致性（硬件和软件）、设计实现和功能需求的一致性、功能需求和测试描述的一致性。

3.6.4系统维护

本项目中，技术支持小组的任务一方面是保证对项目客户的跟踪服务，另一方面是确保该项目的技术咨询工作。

系统维护期，对于一般性的错误，如操作不当等引起的问题，全部由技术支持小组执行完成，但需要用户测试确认上线。

如果较大的修改则需要走变更控制流程，填写变更申请，经项目组讨论分析可行方案在由技术支持小组实施，通过测试后方可提交用户。

在这个过程中质量人员需要对维护过程和维护记录单进行检查。