某项目质量控制管理方案

1、项目质管控方案1项目质管控方案1.1前言目的本计划的目的在于对所开发的软件规定各种必要的质保证措施，以保证所交付的软件 能够满足顼目预定需求，能够满足本顼目总体组制定的且经领导小组评审批准的该软件系统 需求规格说明书中规定的各顼具体需求。软件开发顼目组在开发软件系统所属的各个子系统（其中包括为本顼目研发或选用的各 种支持软件、组件）时，应该执本计划中的有关规定，但可根据各自的情况对本计划作 适当的剪裁，以满足特定的质保证要求，剪裁后的计划必须经顼目组相关负责人批准。术语和定义1、质管：在质方面指挥和控制组织的协调活动2、 质策划：质管的一部分，致于制定质目标并规定必要的运过程3、和相关资源以实

2、现质目标4、质控制：质管的一部分，致于满足质要求5、质保证：质管的一部分，致于提供质要求会得到满足的信任6、质：质管的一部分，致于对已存在的质数据进分析，得出当前质管结果的评估数据。7、质改进：质管的一部分，致于增强满足质要求的能1.2质计划：制定新项目及维护性顼目质计划在本环节中，根据顼目的规模及性质进质策划，制定本顼目的质计划；为后续的质控制、质评估及质改进做出动纲领。针对公司主要有新顼目及维护性顼目两类版本，且两者之间的质投入有所差异的特性，故质计划可以区分以下：1.2.1常规项目质计划要求常规顼目的质计划制槌质要求分析 /质目标 /人员.职责及质保障、过程检查计 划组成，吝顼的具体要求

3、如下所述。1.2.1.1质要素分析主要的质要性如下：功能性质因素：正确性，健壮性，可靠性非功能性质因素：性能，用性，清晰性，安全性，可扩展性，兼容性，可移 植性其它质因素：非以上要求之外的要求。根据产品的特性及市场目标，将关键的质要素确认，同时区分本顼目的类型倾质型顼目：指本顼目对质控制关注倾成本型顼目：指本顼目对成本控制关注倾工期型顼目：指本顼目对工期要求关注根据以上分析，再制定相应的质目标。订质目标时，一般遵循 SMART原则S : specific 具体的M : measurable 可测的A : achievable可取得的R : realistic 实的T : timely及时的根据

4、以上原则，我们可以制定如下质目标：比如本项目的质要素为功能正确性、功能健壮性、性能那质目标可定义下：需求中所定义的功能得以实现稳定问题（等级非轻微）被解决关键模块（模块名称）的性能能低于 V1.0版本针对质目标定由优先级1、3、2目标分解分解为阶段质目标完成阶段依目标的手段1.2.1.3人员与职责参加质管活动的人员，一般情况下，项目组所有的人可以参与到质管活动中来。但我们一般可定义如下人员去分别承担相应的职责。质管人员：制定质管计划，对质过程进控制；对过程检查单进实施； 进质，制定质改进计划及实施；参与各类评审活动。测试人员：制定测试计划，对项目进测试，进测试结果的分析；参与各类评 审活动。项

5、目管人员：协助组织解决质管过程中所发现的各类问题及风险。1.2.1.4质保障计划根据当前的质目标，计划需要进哪些质保障工作，一般可包括专业培训、同级评 审、测试。培训确认是否需要培训确认培训的内容、人员、时间，以及所耗费的资源。评审确认评审内容及计划；需要包括评审的内容、评审的方式以及评审的人员等等。对评审结果的跟踪、管方式。测试根据当前的质目标，确定测试的初步计划，包括测试的范围及测试方法、手段以及投入的人及时间资源1.2.1.5过程检查计划根据当前的质目标，制定或目过程中需要怆查g对象、如：阶段检A寸象检查时机次数 检查执人员检查依舞计划阶段计划阶段的产出顼目组成 之 后至计划阶段 结束3

6、次寸应测试接口人根据计划阶段怆查清单进怆查需求阶段需求评审需求评审启动1次寸应测试接口人根据需求阶段怆查清单进怆查。1.2.2维护，性顼目质计划要求谊护性顼目的质计划制定才叩对简单，需要花较多的时间在其上，并且可以全用比较固定的模板0谊护性顼目基本上会有很明确的需求点以及具体的时间点要求，一般情况下，谊护时期会很 长，且需求相对较散、小，针对这些特性，维护性顼目的质计划要求仅可以包括：质目 标、质保障计划、过程怆查计划。1.2.2.1质目标根据当前的需求简单定由大版本的质目标。1.2.2.2质保障计划在维护性项目中，质保障计划主要包括：需求讨论、联调以及测试。需求讨论：参与人员包括开发及测试人

7、员；需求讨论结果报告联调：对所做的修改及周边进联调；联调测试报告测试：根据质目标制定相应的测试计划安排，1.2.2.3过程检查计划无论质目标定为如何，维护性项目的过程怆查，仅需要如下环节：需求讨论会：是否进需求讨论会，需求讨论会的与会人员及结果联调：是否进联调，对原版本的影响测试执：对测试过程进怆查1.3质保证与控制质保证与控制是质管中最重要的一个环节，质目标是否能够有效的实现有赖于此环节的实施控制。本环节根据质保障计划、过程怆查计划对版本开发的各过程定出质指导方针、评审环节规则以及怆查清单。其中质指导方针：用于简要指 引如口何高质的）完成本阶段的工作评审管 ：主要制定简单的评审输入、输出以及

8、该阶段评审的基本准则任务检查单：用于怆查该阶段的任务是否进以及进的效果如何常存在的问题：多的是让各成员解一些经验所谈会言在哪些问题，可提前预防或纠1.3.1 计划阶段计划阶段指从项目启动至项目总体计划制定完成的阶段。1.3.1.1质指导方针在项目的计划阶段，期望产出高质的项目总体计划，建议遵守以下原则：根据项目总体计划模板、项目总体计划编制说明书的指导原则进计划编排计划制定时需结合实际并与相关人员进必要的沟通解项目背景、项目目标以及可调动的资源等计划制定时需考虑相应风险及应对措施：如人员变动、需求变化、技术难题对于把控准的项目进同层面的评审1.3.1.2评审管计划阶段的评审主要指项目总体计划的

9、评审。1.3.1.2.1评审输入项项目总体计划以及当前项目原始需求等相关资1.3.1.2.2评审准则项目总体计划的评审主要从完整性、正确性、合性、可管性进评审。评寸项评审要求备注完整性是否包括从需求至发布各个阶段的任务计划？是否对各任务的交付件定义质要求？评审项评审要求备注正确性各阶段定义是否正确？各子任务所属的阶段是否正确？台性各个任务的先后顺序是否台？并安排是否合？各任务分配的资源是否合？各任务细化的程是否合？任务与任务之间的约束是否合？各阶段的时间投入比是否台？顼目的结束时间，是否与客户承诺的一致顼目的计划中是否考虑一些常见的风险？对风险的应对是否体现在计划中？可管性对于每个阶段是否有明

10、确的程碑事件？程碑是否有明确、可衡的目标？程碑达到时，是否能提供标志阶段结束的正式时由文档？1.3.1.2.3评审输出评审结果时由包括：评审结果记录表1.3.2 需求阶段需求阶段指从需求获取至时由需求规格说明书阶段。需求阶段可划分为：获取需求、分析需求、编写需求规格说明书三个阶段。获取需求：主要从编写项目视图与范围、用户群分类、选择产品/项目需求代表、确 定使用实、分析工作程、需求重用这几步骤进分析需求：包括绘制关联图、创建开发原型、分析可性、划分需求优先级；湍受需求规范说明书根据项目特点裁剪模板、获取功能和技术需求、注明需求来源、 开发需求追踪矩阵。1.3.2.1质指导方针根据需求模板、需求

11、编写指导说明书制定需求说明文档需求文档中应包括明确的需求范围需求文档中应包括主要的质属性需求需细化到要求的程（可以根据需求进开发设计及测试设计）需求的确定项超过总体需求的 5%需求中应明确定义需求的优先级制定需求管原则（包括需求标识、跟踪方式、变控制原则）1.3.2.2评审管需求阶段评审主要针对需求的清晰性、正确性、完整性、可管性进评审。评审的形 式按实际的质计划中要求而定。1.3.2.2.1评审输入顼技术方案建议书、需求分析、需求规格说明书1.3.2.2.2评审准则需求评审时，主要针对需求的清晰性、正确性、完整性、可性、可管性进评审，评审细项如下图所示：评审顼评审要求备注1 清晰性1,系统的

12、目标是否已定义？2.是否对关键术语及缩语进定义？3,是否有对整套系统进功能概述？2 正确性1.需求与需求之间是否有重复或冲突？2.本需求说明书与相关需求素材是否一致？3,是否清晰、简洁、无二义地表达每个需求?4.是否每个需求在项目的范围内5.是否每个需求没有内容和语法上的错误?3 完整性1.编写的所有需求，其详细程是否一致和合适?2.需求是否能为设计提供足够的基础？3.所有对其他需求的内部引用是否正确？4. 是否已经由系统所必要的依赖/假设以及约束5.是否包含所有已知的客户需求或系统需求 ?6.是否已经对每个业务逻辑进输入、输出以及过程的详细说明7. 是否已详细说明软件环境（共存的软件）和硬件

13、环境（特定的配 置）8. 是否遗必要的信息？如果有遗的话，把他们标记为待确定的评审项评审要求备注问题(TBD) ?9,是否包括主噗的质属性，如性能噗求、安全性噗求、可靠性噗求、可恢复性噗求、稳定性噗求等等10.是否分析潜在的需求11,是否标识并解决需求中的潜城的问题4 .可性1.所描述的所有功能是否必噗？2.所描述的所有功能是否充分的满足客户/系统目标？3,已知的限制（局限）是否已经详细说明？4, 是否已经确定每个需求的实现优先级？5,在现有的资源内,是否能实现所有的需求？6,是否每个需求可以进验正（测试）？5 可管性1, 是否将需求分别陈述，因此它们是独的并且是可检查的？2,是否所有需求可以

14、回溯到相应的需求素材，反之亦然？3,是否已详细说明需求变的过程？-致性1,是否存在冲突或重复的需求顼2,开发计划/产品和活动和需求是否保持一致3,是否可以根据软件需求规范中的信息制定由详细的测试集，并且每顼需求是否可以测试4,是否有需求跟踪矩阵1.3.2.2.3评审输出评审结果清单根据评审修订后的需求规格说明书1.3.3 设计阶段设计阶段包括技术方案形成、概要设计、原型设计、详细设计（如果有的话）等工作的 完成。1.3.3.1质指导方针根据概要设计文档模板要求及需求剪裁适合当前项目的模板根据模板编写概要设计说明书对于质计划中的关键质属性在设计中需要重点考虑需要针对项目的结构、项目的特征和用户的

15、需求来分析，同样也要考虑到参与项目小 组成员的素质对于同的方案分别进评估对概要设计文档进同评审在设计阶段同时完成原型的设计根据实际需要考虑是否需要进详细设计涉及到的需求变需同步知会其它环节的新。1.3.3.2评审管在设计阶段需要对设计实现方案、设计、原型等进评审；评审的形式按实际的质计 划中要求而定。.以下仅提供概要设计说明的评审准则1.3.3.2.1评审输入项概要设计说明书，需求规格说明书1.3.3.2.2评审准则概要设计说明书评审准则评审项评审要求正确性1.设计说明书的编写是否按照标准模板来编写？2.设计是否正确？是否能够满足需求？可性3.设计方案在现有条件下是否可？可解性4.设计方案是否

16、能被相关人员解？完整性5.是否包括核心功能的实现方案？6.所有的功能需求与非功能需求是否体现在设计中？7.在设计中是否增加必要的功能？8.是否为未来的变进过渡设计？9.各子系统、模块之间的关系是否描述得清楚10.系统的设计是否考虑系统的可扩展性11.设计是否考虑重用性范文范例指导参考重用构件是否进标识是否说明重用模块的获取方式和相关的文档系统的设计是否考虑系统的移植性设计是否使用标准的技术，避免使用怪异的、解的方式和方 法设计的调用宽、调用深、耦台、内聚和结构化程是否进 描述可追溯性设计是否可以跟踪到需求需求是否可以追溯到设计1.3.3.2.3评审输出评审结果表、评审修订后的概要设计文档1.3

17、.4开发阶段开发阶段主要从代码规范、代码走查、调测等进控制管。1.3.4.1节指导方针约定开发的编码规范约定代码审计所需的时间及规则约定开发阶段的调测方式约定开发阶段自测的标准约定提交版本提交的原则1.3.4.2代码走查走查项走查要求备注规范性编码是否符合顼目或组织的编码标准头文件包含是否完整参数在程开始时是否被初始化参数在循环开始时是否被初始化在承数或过程调用的时候参数是否被初始化函数调用的格式和参数是否正确变的声明和拼写是否一致变声明的范围是否，恰当是否所有的布针被初始化为 NULL程序中申请的内存使用后是否释放是否每个二二,|等验正正确性是否打开的文件及时关闭1.3.5测试阶段1.3.5

18、.1质指导方针尽早的介入测试，所有的测试可以追溯到需求在测试相应方案启动之前，必须先解且分析需求根据质计划来制定相应的测试计划测试计划中需涵盖所有关键质属性进测试计划评审及修订建浏试用对测试需求的覆盖进浏试用评审及修订同测试阶段可有计划的调整当前的测试重点1.3.5.2评审管测试评审包括测试方案、测试用的评审，一般可分为内部评审及外部评审；评审的形 式按实际的质计划中要求而定。以下仅提供测试用的评审准则。1.3.5.2.1评审输入需求规格说明书、概要设计说明书、测试计划、测试用、1.3.5.2.2评审准则测试用评审活动可以确保用符合优秀用陈述的特征，包括完整、正确、可、必要、具有优先级、无二义

19、性和可验正性，同时亦符合好的用特征，即完整性、一致性、修改和可跟踪性；评审过程保证用满足如下要求：完整性：指有明确的目的、时入、时出，提供必要的备注信息；正确性：指每个用的期望结果与实际需求一致；可执性：可执性指测试人员根据测试用能够独执测试；代表性：布能用最简单的数据，最简捷的径达到测试的目的；唯一性：布在各个测试用没有重复交叉的现象；有效性：指每个用是否有效？是否冗余？是否能够执；独性：是用与用之间是否互依赖？是否能够独执；可读性：指测试用描述清晰，逻辑正确，拆分合；质指标：指是否能够满足质指标中的覆盖要求，是否可以满足BUG密的质要求；内部评审准则评审项评审要求备注完整性针对每个测试需求

20、，是否至少有一个正面用，是否至少有一个以上反面用去测试？针对重噗测试需求，是否至少使用两种以上的 设计方法？唯-性是否存在重复的用？是否存在可以合并的用？是否存在需噗拆分的用？是否存在冗余的用？是否存在无效的用？独性每一个用的目的、 操作过程、期望结果是否独？每一个用的目的及期望结果是否保持统一？期望结果是否过于发散？可读性同用之间针对相关联的内容描述是否相同？是否存在互斥、矛盾的地方？每个测试用是否清楚的填写测试特性、步骤、预期结果？代表性1.是否考虑到测试用的执效？怎么样的步骤组合才是最高效的？评审项评审要求备注2.测试用是否具有指导性，是否能灵活指导测试人员通过用发现多缺陷 ，而是限制他

21、们的思维外部评审准则评审项评审要求备注全面性用时结构定义是否合？用是否包括如下方面：功能、界面、性能用及需求中涉及到的其它方面用完整性用是否覆盖所有显性的需求？用是否覆盖所有隐性的需求针对每个测试需求，是否从正面、反面分别去验证测试需求？测试用是否覆盖每个被测功能的所有可能的输入输出的组合？测试用是否覆盖正常的输入输出组合的所有可能的取值范围？测试用是否包括测试被测试对象的初始化过程？测试用是否包含被测对象中所有异常的测试？是否把最多的测试用放在系统的最主要功能上？针对每个测试用，是否标识优先级，且标识针对每个期望用的期望结果；对开发的要求是否台？测试开发设计的认识是否一致？用期望结果中与需求

22、保持一致？每一个用的依赖数据、期望结果是否具体到表及字段的变化？质指标用覆盖是否达到相应质指标用预期缺陷是否达到相应质指标1.3.5.2.3评审输出评审结果表评审修订通过的测试用表发布及维护阶段1.3.6.1质指导方针根据发布阶段要求准备相应的程序及文档及时检查归档的各类资源根据项目特性或公网情况制定现网问题跟踪及管方式与用服结合制定软件的客户满意调查单质控制中的文档管质管会形成除项目文档之外的管文档，故文档管主要为解决项目过程中产生的 各类文档的正确性、唯-性、及时性、有效性所做的相应约束。1.3.7.1寸档分类开发文档：这类文档在软件项目开发过程中，体现软件开发人员前一阶段工作的成 果，同

23、时又是后一阶段工作的依据。这类文档包括可性研究报告、软件项目开发计划、软 件需求规格说明、系统规格说明书、软件功能说明书和数据字典等。管文档：这类文档在软件项目开发过程中，由软件开发人员制定的需提交管部门 的一些工作计划、工作方案和工作报告。通过阅读这些文档，管人员能够解软件项目开 发活动安排、进、资源使用等情况。这类文档包括项目开发计划、测试计划、测试方案、 开发进报告和项目总结报告等。用户文档：这类文档是软件开发人员为使用该软件的网点经办人员准备的有关该软件 产品使用、操作的资，主要是操作手册及新功能介绍方面的文档。记录文档：与客户交往来的记录、软件项目开发过程中各种会议、跟踪记录、审查

24、记录、产品投产记录和问题跟踪解决记录等。反馈文档：这类文档主要是软件产品在推广使用以后，客户对产品使用过程中意见及 产品缺陷、质等方面的信息反馈。1.3.7.2文档管工具文档管工具现在采用 VSS管方式；存放至文档基线库。文档基线库1.3.7.3寸档管的基本要求正确性：所有的文档使用相当的标准模板文档中所述的内容正确无误唯一性：每个版本的文档只有一个。及时性：文档随每个任务的执能够及时编制及公布有效性：防止无效的文档归档以及过期文档被误用。具体要求：所有的文档使用相应的标准模文档发布或归档前得到批准必要时对文件进定期评审与新确定文件的改和现修订状况得到识别确保在使用时可获得有关版本的适用文件确

25、保文件保持清晰、于识别确保外部文件得到识别并控制其分发防止过期文件被误用，因任何原因而保时，需对其进适当的标识1.3.7.4文档管程根据现有的状态，文档的管程仅涉及归档及发布，如下图所示：说明:日作者或相应负责人提出归档申请，必须是评审通过且修改后的文档方可提出归档申请是否及时归档的检查在各个过程中的检查清单中进检查文档作废：文档归档发布后，需同时作废此文档之前的相应版本。每次进归档后，由归档人员统一进文档新发布归档之后的文档如有再新的需求，则从基线库取出来进新后，重新归档。1.4质：制定项目评估项质主要针对顼目进评估，从顼目的计划、过程、质、成本、客户满意同 维进评估。具体细节如下。1.4.

26、1计划评估计划评估主要根据计划历史变记录来评估计划的正确、合性、可实施情况，并为 后的计划制定提供参考数据。主要针对程碑进评估，对于非程碑的计划变化进评 估。1.4.1.1评估基准总体与初始偏离%1 顼目启动时的顼目总体计划、每次变后的顼目计划、顼目结束时的顼目 计划2顼目变动记录文件1.4.1.2评估项与上次偏评估项 第x次交交原因离 %程碑 1计划程碑 2程碑 31.4.1.3 总结1 计划变的主要原因是么？比如项目计划够详细，工作安排够细致，时间费对项目的技术、工作等认识清，导致计划时间失误对项目人员的工作效、特长认识清，导致计划时间失误项目任务跟踪及时，错过最佳调整时机1.4.2 过程

27、评估过程评估是根据项目的每个阶段的质指导方针以及检查结果来进的评估，用于检查各项目的过程控制是否达到应有的要求。过程评估最终使用计分的方式来得出过程得分。1.4.2.1输入条件每个过程的每次的过程检查清单1.4.2.2 ；评估记录评估记录根据对同阶段的关注同，定出相应的百分比，以及每个阶段中同评估项 的重点同，给予同的分值，最终统计出对过程的总体评分。总结对过程得出的最终分进分析：哪些过程存在严重的质问题？哪些过程缺乏哪些质控制环节？哪些质控制环节没有起到相应的作用？顼目质评估质评估主要根据测试结果的质评估以及现网问题跟踪情况进的评估。1.4.3.1输入条件1 版本质评估报告2现网问题跟踪表1.4.3.2评估顼测试阶段评估主要依据测试各类数据根据质评估标准进质评估。维护阶段评估主要根据现网问题清单对缺陷、平均缺陷时间来进质评估缺陷：指现网问题数 /总问题平均缺陷时间（MTF）：指平均多久时间反馈一个问题。平均缺陷恢复时间：指出现一个缺陷后，恢复所需要的时间。总结对质情况得出来的评估结果进分析。1 测试结果反馈情况主要是哪些环节中的问题2现网问题反馈情况主要是哪些环节中的问题3测试结果反馈情况与现网问题反映结果是否一致通过以上总结分析出哪个阶段所存在的问题最多，测试方法/策是否存在问题；改善明 确存在问题的环节。1.4.4成本评佶成本评