软件质量管理手册优质资料

软件质量管理手册优质资料(可以直接使用，可编辑优质资料，欢迎下载）

软件质量管理手册优质资料(可以直接使用，可编辑优质资料，欢迎下载）质量管理手册目录1前言51.1读者对象51.2目的和范围51.3术语和定义52总体说明53质量计划：制定新项目及维护性项目质量计划53.1常规项目质量计划要求6质量要素分析6质量目标6人员与职责7质量保障计划7过程检查计划73.2维护性项目质量计划要求8质量目标8质量保障计划8过程检查计划84质量保证与控制84.1计划阶段9质量指导方针9评审管理9计划阶段检查单10常存在的问题114.2需求阶段11质量指导方针11评审管理12需求阶段检查单13常存在的问题144.3设计阶段14质量指导方针14评审管理14设计阶段检查单15常存在的问题164.4开发阶段16质量指导方针16代码走查17开发阶段检查单17常存在的问题184.5测试阶段18质量指导方针18评审管理18检查清单21常存在的问题224.6发布及维护阶段23质量指导方针23发布及维护阶段检查清单23常存在的问题244.7质量控制中的文档管理24文档分类24文档管理工具24文档管理的基本要求24文档管理流程255质量度量：制定项目评估项255.1计划评估26评估基准26评估项26总结265.2过程评估26输入条件27评估记录表27总结285.3项目质量评估28输入条件28评估项28总结295.4成本评估29输入条件29评估项29总结305.5客户满意度评估31输入条件31评估项31总结316质量改进316.1现存在的质量问题326.2质量改进措施32问题XXXX32产生原因分析32预防措施327附录一：评审过程检查表338附录二：参照及依从的规范文档清单349附录三：项目管理跟踪管理34前言读者对象本文档的读者对象包括质量管理人员、项目组成员及研发管理人员。目的和范围本文档的目的为了指导研发部进行质量管理的步骤及方法/原则。适用范围为研发部的质量管理作参考，以杜绝或减少研发过程中出现的质量问题，并对质量管理结果作出相应的改善。术语和定义质量管理：在质量方面指挥和控制组织的协调活动质量策划：质量管理的一部分，致力于制定质量目标并规定必要的运行过程和相关资源以实现质量目标质量控制：质量管理的一部分，致力于满足质量要求质量保证：质量管理的一部分，致力于提供质量要求会得到满足的信任质量度量：质量管理的一部分，致力于对已存在的质量数据进行分析，得出当前质量管理结果的评估数据。质量改进：质量管理的一部分，致力于增强满足质量要求的能力总体说明由于现有的研发过程成熟程度较低，质量管理不能一开始即从非常高的标准入手，故根据研发部的现状，质量管理初步从4个方面着手：计划（确定过程）、保证及检查（控制过程）、评估（测量过程）、改进（改进过程）。以预防式管理为方向，控制、检查为手段，持续改进并提升项目质量为最终目的。鉴于质量管理在本阶段为初次正式引入，故对控制及检查、评估环节中的要求并不完善，以减少实施过程中过多的阻碍。质量计划：制定新项目及维护性项目质量计划在本环节中，根据项目的规模及性质进行质量策划，制定本项目的质量计划；为后续的质量控制、质量评估及质量改进做出行动纲领。针对公司主要有新项目及维护性项目两类版本，且两者之间的质量投入有所差异的特性，故质量计划可以区分以下：常规项目质量计划要求常规项目的质量计划制定按质量要求分析/质量目标/人员.职责及质量保障、过程检查计划组成，各项的具体要求如下所述。质量要素分析主要的质量要性如下：功能性质量因素：正确性，健壮性，可靠性非功能性质量因素：性能，易用性，清晰性，安全性，可扩展性，兼容性，可移植性其它质量因素：非以上要求之外的要求。根据产品的特性及市场目标，将关键的质量要素确认，同时区分本项目的类型倾质量型项目：指本项目对质量控制更关注倾成本型项目：指本项目对成本控制更关注倾工期型项目：指本项目对工期要求更关注根据以上分析，再制定相应的质量目标。质量目标订立质量目标时，一般遵循SMART原则S：specific具体的M：measurable可测量的A：achievable可取得的R：realistic切实的T：timely及时的根据以上原则，我们可以制定如下质量目标：比如本项目的质量要素为功能正确性、功能健壮性、性能那质量目标可定义例下：需求中所定义的功能都得以实现不稳定问题（等级非轻微）都被解决关键模块（模块名称）的性能不能低于V1.0版本……针对质量目标定出优先级1、3、2目标分解分解为阶段质量目标完成阶段质量目标的手段人员与职责参加质量管理活动的人员，一般情况下，项目组所有的人都可以参与到质量管理活动中来。但我们一般可定义如下人员去分别承担相应的职责。质量管理人员：制定质量管理计划，对质量过程进行控制；对过程检查单进行实施；进行质量度量，制定质量改进计划及实施；参与各类评审活动。测试人员：制定测试计划，对项目进行测试，进行测试结果的度量分析；参与各类评审活动。项目管理人员：协助组织解决质量管理过程中所发现的各类问题及风险。质量保障计划根据当前的质量目标，计划需要进行哪些质量保障工作，一般可包括专业培训、同级评审、测试。培训确认是否需要培训确认培训的内容、人员、时间，以及所耗费的资源。评审确认评审内容及计划；需要包括评审的内容、评审的方式以及评审的人员等等。对评审结果的跟踪、管理方式。测试根据当前的质量目标，确定测试的初步计划，包括测试的范围及测试方法、手段以及投入的人力及时间资源过程检查计划根据当前的质量目标，制定项目过程中需要检查的对象、例如：阶段检查对象检查时机次数检查执行人员检查依据计划阶段计划阶段的产出项目组成立之后至计划阶段结束3次对应测试接口人根据计划阶段检查清单进行检查需求阶段需求评审需求评审启动1次对应测试接口人根据需求阶段检查清单进行检查。维护性项目质量计划要求维护性项目的质量计划制定相对简单，不需要花较多的时间在其上，并且可以套用比较固定的模板。维护性项目基本上会有很明确的需求点以及具体的时间点要求，一般情况下，维护时期会很长，且需求相对较散、小，针对这些特性，维护性项目的质量计划要求仅可以包括：质量目标、质量保障计划、过程检查计划。质量目标根据当前的需求简单定出本版本的质量目标。质量保障计划在维护性项目中，质量保障计划主要包括：需求讨论、联调以及测试。需求讨论：参与人员包括开发及测试人员；需求讨论结果报告联调：对所做的修改及周边进行联调；联调测试报告测试：根据质量目标制定相应的测试计划安排，过程检查计划无论质量目标定为如何，维护性项目的过程检查，仅需要如下环节：需求讨论会：是否进行了需求讨论会，需求讨论会的与会人员及结果联调：是否进行了联调，对原版本的影响测试执行：对测试过程进行检查子过程评估项评估结果得分单项分*百分比有(√)没有(×)N/A需求讨论（50%）是否发起需求讨论会？（60分）与会人员涉及是否合理？(40分)联调测试（20%）进行了联调测试（60分）联调是否有效发现的问题数是测试的20%(40分)测试（30%）测试具有用例或测试点？(50分)测试执行是否能被跟踪(50分)质量保证与控制质量保证与控制是质量管理中最重要的一个环节，质量目标是否能够有效的实现都有赖于此环节的实施控制。本环节根据质量保障计划、过程检查计划对版本开发的各过程定出质量指导方针、评审环节规则以及检查清单。其中质量指导方针：用于简要指引如何高质量的完成本阶段的工作评审管理：主要制定简单的评审输入、输出以及该阶段评审的基本准则任务检查单：用于检查该阶段的任务是否进行以及进行的效果如何常存在的问题：更多的是让各成员了解一些经验所谈会存在哪些问题，可提前预防或纠正计划阶段计划阶段指从项目启动至项目总体计划制定完成的阶段。质量指导方针在项目的计划阶段，期望产出高质量的项目总体计划，建议遵守以下原则：根据《项目总体计划模板》、《项目总体计划编制说明书》的指导原则进行计划编排计划制定时需结合实际并与相关人员进行必要的沟通了解项目背景、项目目标以及可调动的资源等计划制定时需考虑相应风险及应对措施：如人员变动、需求变化、技术难题对于把控不准的项目进行不同层面的评审评审管理计划阶段的评审主要指项目总体计划的评审。评审输入项《项目总体计划》以及当前项目原始需求等相关资料评审准则项目总体计划的评审主要从完整性、正确性、合理性、可管理性进行评审。评审项评审要求备注完整性是否包括从需求至发布各个阶段的任务计划？是否对各任务的交付件定义了质量要求？正确性各阶段定义是否正确？各子任务所属的阶段是否正确？合理性各个任务的先后顺序是否合理？并串行安排是否合理？各任务分配的资源是否合理？各任务细化的程度是否合理？任务与任务之间的约束是否合理？各阶段的时间投入比例是否合理？项目的结束时间，是否与客户承诺的一致项目的计划中是否考虑一些常见的风险？对风险的应对是否体现在计划中？可管理性对于每个阶段是否有明确的里程碑事件？里程碑是否有明确、可衡量的目标？里程碑达到时，是否能提供标志阶段结束的正式输出文档？评审输出评审结果输出包括：《评审结果记录表》《修订后的项目总体计划》计划阶段检查单编号：项目名称项目编号软件项目经理此次检查所费时间报告人日期检查内容已经完成部分完成尚未完成不适用注释项目估算对项目进行了合理的分解，并区分复杂度对项目进行了规模和工作量估算，并符合估算过程对项目进行了进度、风险、资源、成本估算对估算结果进行了评审，并符合要求策划过程选择了合适的生命周期模型同时考虑了项目管理、集成、测试、SCM、SQA等工作定义了合理的里程碑且每个里程碑的目标清晰已经剔除了停工、假期等影响工作时间的因素策划形成的计划与用户要求、合同等不相矛盾计划评审及跟踪计划发起了评审计划评审过程符合公司规定、标准要求计划评审过程有效（评审所发现的问题数（用于检查评审是否有效，是否达到预期，以及交付件的质量）评审所反馈的问题已经妥善解决修订后的计划已经纳入基线库审核签字角色姓名签字日期软件项目经理研发经理常存在的问题计划中并行工作先后顺序安排不合理计划中没有预留任何应对风险的措施计划中未包括整个项目的所有工作计划中不确定的因素过多需求阶段需求阶段指从需求获取至输出需求规格说明书阶段。需求阶段可划分为：获取需求、分析需求、编写需求规格说明书三个阶段。获取需求：主要从编写项目视图与范围、用户群分类、选择产品/项目需求代表、确定使用实例、分析工作流程、需求重用这几步骤进行分析需求：包括绘制关联图、创建开发原型、分析可行性、划分需求优先级；编写需求规范说明书：根据项目特点裁剪模板、获取功能和技术需求、注明需求来源、开发需求追踪矩阵。质量指导方针根据《需求模板》、《需求编写指导说明书》制定需求说明文档需求文档中应包括明确的需求范围需求文档中应包括主要的质量属性需求需细化到要求的程度（可以根据需求进行开发设计及测试设计）需求的不确定项不超过总体需求的5%需求中应明确定义需求的优先级制定需求管理原则（包括需求标识、跟踪方式、变更控制原则）评审管理需求阶段评审主要针对需求的清晰性、正确性、完整性、可管理性进行评审。评审的形式按实际的质量计划中要求而定。评审输入项《技术方案建议书》、《需求分析》、《需求规格说明书》评审准则需求评审时，主要针对需求的清晰性、正确性、完整性、可行性、可管理性进行评审，评审细项如下图所示：评审项评审要求备注1．清晰性系统的目标是否已定义？是否对关键术语及略缩语进行了定义？是否有对整套系统进行了功能概述？2．正确性需求与需求之间是否有重复或冲突?本需求说明书与相关需求素材是否一致？是否清晰、简洁、无二义地表达了每个需求?是否每个需求都在项目的范围内是否每个需求都没有内容和语法上的错误?3．完整性编写的所有需求，其详细程度是否一致和合适?需求是否能为设计提供足够的基础?所有对其他需求的内部引用是否正确?是否已经列出了系统所必要的依赖/假设以及约束是否包含了所有已知的客户需求或系统需求?是否已经对每个业务逻辑进行输入、输出以及过程的详细说明是否已详细说明了软件环境（共存的软件）和硬件环境（特定的配置）是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题(TBD)?是否包括了主要的质量属性，例如性能要求、安全性要求、可靠性要求、可恢复性要求、稳定性要求等等是否分析了潜在的需求是否标识并解决了需求中的潜城的问题4．可行性所描述的所有功能是否都必要？所描述的所有功能是否充分的满足客户/系统目标？已知的限制（局限）是否已经详细说明？是否已经确定每个需求的实现优先级?在现有的资源内,是否能实现所有的需求?是否每个需求都可以进行验证（测试）？5．可管理性是否将需求分别陈述，因此它们是独立的并且是可检查的？是否所有需求都可以回溯到相应的需求素材，反之亦然？是否已详细说明需求变更的过程？一致性是否存在冲突或重复的需求项开发计划/产品和活动和需求是否保持一致是否可以根据软件需求规范中的信息制定出详细的测试集，并且每项需求是否可以测试是否有《需求跟踪矩阵》评审输出《评审结果清单》《根据评审修订后的需求规格说明书》需求阶段检查单项目名称项目编号软件项目经理此次检查耗费时间报告人日期检查内容是否无法确认N/A注释需求确立系统需求明确及其分配已形成文档软件需求明确并按照模版形成文档需求管理中主要的质量属性已经确认已与受影响的组和个人协商需求的约定需求中不可测试的部分已经进行标识需求评审及跟踪需求经过评审需求评审过程有效（发现的问题达到一定级别）需求评审中发现的问题都已妥善解决需求已经过客户或高级管理者的认可并签字确认修订后的需求规格说明书是否纳入基线库需求变更控制已经建立需求变更控制流程需求的变动情况是否在软件需求说明书进行登记内部受影响的组织已了解和承诺更改对更改所造成的风险和影响已进行识别、评价并文档化进度跟踪进度是否延期？如果延期，延期是否在可控范围内？审核签字角色姓名签字日期软件项目经理研发总监常存在的问题需求未经过分析直接转给其它人员需求不够细化，开发及测试设计无法进行需求中不确认的需求点过多需求不完整、不全面设计阶段设计阶段包括技术方案形成、概要设计、原型设计、详细设计（如果有的话）等工作的完成。质量指导方针根据概要设计文档模板要求及需求剪裁适合当前项目的模板根据模板编写概要设计说明书对于质量计划中的关键质量属性在设计中需要重点考虑需要针对项目的结构、项目的特征和用户的需求来分析，同样也要考虑到参与项目小组成员的素质对于不同的方案分别进行评估对概要设计文档进行同行评审在设计阶段同时完成原型的设计根据实际需要考虑是否需要进行详细设计涉及到的需求变更需同步知会其它环节的更新。评审管理在设计阶段需要对设计实现方案、设计、原型等进行评审；评审的形式按实际的质量计划中要求而定。以下仅提供概要设计说明的评审准则评审输入项《概要设计说明书》，《需求规格说明书》评审准则概要设计说明书评审准则评审项评审要求正确性设计说明书的编写是否按照标准模板来编写?设计是否正确？是否能够满足需求？可行性设计方案在现有条件下是否可行？可理解性设计方案是否能被相关人员理解？完整性是否包括核心功能的实现方案？所有的功能需求与非功能需求是否都体现在了设计中？在设计中是否增加了不必要的功能？是否为未来的变更进行了过渡设计？各子系统、模块之间的关系是否描述得清楚系统的设计是否考虑了系统的可扩展性设计是否考虑了重用性重用构件是否进行了标识是否说明了重用模块的获取方式和相关的文档系统的设计是否考虑了系统的易移植性设计是否使用标准的技术，避免使用怪异的、不易理解的方式和方法设计的调用宽度、调用深度、耦合度、内聚度和结构化程度是否进行了描述可追溯性设计是否可以跟踪到需求需求是否可以追溯到设计评审输出《评审结果列表》、评审修订后的《概要设计文档》设计阶段检查单项目名称项目编号软件项目经理此次检查耗费时间报告人日期检查内容已经完成部分完成尚未完成不适用注释设计确认是否具有概要设计说明书设计说明书的编写按照标准模板来编写设计评审及跟踪设计经过评审设计评审过程有效（用于检查评审是否有效，是否达到预期，以及交付件的质量）设计评审中发现的问题都已妥善解决修订后的设计说明书是否纳入文档基线库设计变更控制已经建立设计变更控制流程设计冻结过程原型确认原型设计完成原型评审执行设计评审中发现的问题都已妥善解决原型完整性（可供演示的完整页面）进度跟踪是否按进度进行？如进度延期，延期是否在可控范围内？审核签字角色姓名签字日期软件项目经理研发总监常存在的问题存在未攻克的技术难题需求基线变动太多而造成设计变化多设计方案不全面，不完整设计方案中所使用的技术未经验证开发阶段开发阶段主要从代码规范、代码走查、调测等进行控制管理。质量指导方针约定开发的编码规范约定代码审计所需的时间及规则约定开发阶段的调测方式约定开发阶段自测的标准约定提交版本提交的原则代码走查走查项走查要求备注规范性编码是否符合项目或组织的编码标准头文件包含是否完整参数在程度开始时是否被初始化参数在循环开始时是否被初始化在承数或过程调用的时候参数是否被初始化函数调用的格式和参数是否正确变量的声明和拼写是否一致变量声明的范围是否恰当是否所有的指针都被初始化为NULL程序中申请的内存使用后是否释放是否每个==，||等都验证了正确性是否打开的文件都及时关闭了开发阶段检查单输入条件：项目当前的《项目总体计划》；《代码走查结果清单》；《单元测试结果清单》；《联调测试结果清单》检查项：项目名称项目编号软件项目经理此次检查耗费时间报告人日期检查内容已经完成部分完成尚未完成不适用注释代码开发规范编码是否符合项目或组织的编码标准代码开发阶段工作进行代码走审代码走查有效（问题数发现达*个/代码行以上）进行单元测试单元测试有效（问题数发现达*个/代码行以上）进行联调联调是否有效（问题数发现达*个/代码行以上）进度跟踪是否按进度进行？如进度延期，延期是否在可控范围内？审核签字角色姓名签字日期软件项目经理研发总监常存在的问题没有形成项目组内的编码规范没有进行代码审查，问题无法被暴露没有进行单元测试造成联调时间加倍增长没有进行联调造成接口级问题非常之多送测版本实际未达到送测要求没有进行联调造成版本送测多次方成功测试阶段质量指导方针尽早的介入测试，所有的测试都可以追溯到需求在测试相应方案启动之前，必须先理解且分析需求根据质量计划来制定相应的测试计划测试计划中需涵盖所有关键质量属性进行测试计划评审及修订建立测试用例对测试需求的覆盖率进行测试用例评审及修订不同测试阶段可有计划的调整当前的测试重点评审管理测试评审包括测试方案、测试用例的评审，一般可分为内部评审及外部评审；评审的形式按实际的质量计划中要求而定。以下仅提供测试用例的评审准则。评审输入《需求规格说明书》、《概要设计说明书》、《测试计划》、《测试用例》、评审准则测试用例评审活动可以确保用例符合优秀用例陈述的特征，包括完整、正确、可行、必要、具有优先级、无二义性和可验证性,同时亦符合好的用例特征，即完整性、一致性、易修改和可跟踪性；评审过程保证用例满足如下要求：完整性：指有明确的目的、输入、输出，提供必要的备注信息；正确性：指每个用例的期望结果与实际需求一致；可执行性：可执行性指测试人员根据测试用例能够独立执行测试；代表性：指能用最简单的数据，最简捷的路径达到测试的目的；唯一性：指在各个测试用例没有重复交叉的现象；有效性：指每个用例是否有效？是否冗余？是否能够执行；独立性：是用例与用例之间是否互不依赖？是否能够独立执行；可读性：指测试用例描述清晰，逻辑正确，拆分合理；质量指标：指是否能够满足质量指标中的覆盖率要求，是否可以满足BUG密度的质量要求；内部评审准则评审项评审要求备注完整性针对每个测试需求，是否至少有一个正面用例，是否至少有一个以上反面用例去测试？针对重要测试需求，是否至少使用了两种以上的设计方法？唯一性是否存在重复的用例？是否存在可以合并的用例？是否存在需要拆分的用例？是否存在冗余的用例？是否存在无效的用例？独立性每一个用例的目的、操作过程、期望结果是否独立？每一个用例的目的及期望结果是否保持统一？期望结果是否过于发散？可读性不同用例之间针对相关联的内容描述是否相同？是否存在互斥、矛盾的地方？每个测试用例是否清楚的填写了测试特性、步骤、预期结果？代表性是否考虑到测试用例的执行效率？怎么样的步骤组合才是最高效的？测试用例是否具有指导性,是否能灵活指导测试人员通过用例发现更多缺陷,而不是限制他们的思维外部评审准则评审项评审要求备注全面性用例树结构定义是否合理？用例是否包括如下方面：功能、界面、性能用例及需求中涉及到的其它方面用例完整性用例是否覆盖了所有显性的需求？用例是否覆盖了所有隐性的需求针对每个测试需求，是否从正面、反面分别去验证测试需求？测试用例是否覆盖每个被测功能的所有可能的输入输出的组合？测试用例是否覆盖正常的输入输出组合的所有可能的取值范围？测试用例是否包括测试了被测试对象的初始化过程？测试用例是否包含了被测对象中所有异常流的测试？是否把最多的测试用例精力放在系统的最主要功能上？针对每个测试用例，是否标识了优先级，且标识合理？针对每个期望用例的期望结果；对开发的要求是否合理？测试开发设计的认识是否一致？用例期望结果理中与需求保持一致？每一个用例的依赖数据、期望结果是否具体到表及字段的变化？质量指标用例覆盖率是否达到相应质量指标?用例预期缺陷率是否达到相应质量指标?评审输出《评审结果列表》《评审修订通过的测试用例列表》检查清单输入条件：项目当前的《项目总体计划》；《测试计划/用例文档》、《评审结果单》、测试用例/测试执行/BUG单结果数据项目名称项目编号软件项目经理此次检查耗费时间报告人日期检查内容已经完成部分完成尚未完成不适用注释测试计划及设计确认测试计划及用例编制能根据不同质量属性制定不同测试计划测试用例对需求的覆盖达到90%测试评审及跟踪测试计划评审评审结果清单（用于检查评审是否有效，是否达到预期，以及交付件的质量）反馈的问题都妥善解决测试用例评审评审结果（用于检查评审是否有效，是否达到预期，以及交付件的质量）反馈的问题都妥善解决测试跟踪测试执行过程是否被记录及监控BUG单是否被管理质量评估是否进行是否具有测试报告测试报告是否反馈进度跟踪是否按进度进行？如进度延期，延期是否在可控范围内？审核签字角色姓名签字日期软件项目经理研发总监常存在的问题需求或设计变化造成测试时间不够区分哪些会影响关键质量目标，优化测试关键质量目标，对于非关键性的质量因素，可后续再做补充测试。测试环境与实际环境无法保持一致而可能造成问题较多。区分影响及不影响的功能点。对于影响的功能点，在现网布署后，必须再进行现网测试后方可正式投入使用。软件稳定性不够，不可复现问题多稳定测试环境，增加对日志的监控及捕捉测试用例的执行率未达到100%跟进原因，对于非客观原因造成，则可考虑测试用例执行作为项目经理接收测试结束标准。测试用例对需求覆盖率过低提升评审效果，增加用例设计及补充时间段测试用例发现BUG率过低增加用例设计及补充时间段，再进行测试BUG数严重超出预期暂停现有的测试，项目组讨论分析再增加单元或联调测试通过扣，方可再进行版本提交。BUG数没有收敛的趋势寻找是测试原因造成漏测或是开发总产生新BUG漏测：适当的增加单轮测试时间，强调不同维度的测试；多进行交叉测试修改产生过多的新BUG：强调开发的单元测试及走查。BUG返修率过高在修改BUG过程中强调与测试的沟通。BUG修改完成后，完成相应的自测。测试人员提交BUG单时尽量清晰描述BUG单，并附重现条件或日志。发布及维护阶段质量指导方针根据发布阶段要求准备相应的程序及文档及时检查归档的各类资源根据项目特性或公网情况制定现网问题跟踪流及管理方式与用服结合制定软件的客户满意度调查单发布及维护阶段检查清单项目名称项目编号软件项目经理此次检查耗费时间报告人日期检查内容已经完成部分完成尚未完成不适用注释归档确认版本归档项目经理检查权限回收现网问题跟踪现网问题跟踪流程确认反馈的问题管理现网反馈的问题已经妥善解决审核签字角色姓名签字日期软件项目经理研发总监常存在的问题版本忘记归档由项目经理检查归档情况，发现未归档者，可及时提出项目经理未对归档进行检查当根据以上检查单发现未版本，则记未归档及项目经理未检查一次；当出现由于归档资料不全而造成发布给现网出现问题，则记项目经理未检查一次；现网问题解决情况未进行跟踪定期收集信息，对于管理流程及工具可使用研发部整套模式。质量控制中的文档管理质量管理会形成除项目文档之外的管理文档，故文档管理主要为解决项目过程中产生的各类文档的正确性、唯一性、及时性、有效性所做的相应约束。文档分类(1)开发文档：这类文档在软件项目开发过程中，体现了软件开发人员前一阶段工作的成果，同时又是后一阶段工作的依据。这类文档包括可行性研究报告、软件项目开发计划、软件需求规格说明、系统规格说明书、软件功能说明书和数据字典等。(2)管理文档：这类文档在软件项目开发过程中，由软件开发人员制定的需提交管理部门的一些工作计划、工作方案和工作报告。通过阅读这些文档，管理人员能够了解软件项目开发活动安排、进度、资源使用等情况。这类文档包括项目开发计划、测试计划、测试方案、开发进度报告和项目总结报告等。(3)用户文档：这类文档是软件开发人员为使用该软件的网点经办人员准备的有关该软件产品使用、操作的资料，主要是操作手册及新功能介绍方面的文档。(4)记录文档：与客户交流往来的记录、软件项目开发过程中各种会议、跟踪记录、审查记录、产品投产记录和问题跟踪解决记录等。(5)反馈文档：这类文档主要是软件产品在推广使用以后，客户对产品使用过程中意见及产品缺陷、质量等方面的信息反馈。文档管理工具文档管理工具现在采用VSS管理方式；存放至文档基线库。文档基线库文档管理的基本要求正确性：所有的文档都使用相当的标准模板文档中所述的内容正确无误唯一性：每个版本的文档只有一个。及时性：文档随每个任务的执行能够及时编制及公布有效性：防止无效的文档归档以及过期文档被误用。具体要求：所有的文档都使用相应的标准模文档发布或归档前得到批准必要时对文件进行定期评审与更新确定文件的更改和现行修订状况得到识别确保在使用时可获得有关版本的适用文件确保文件保持清晰、易于识别确保外部文件得到识别并控制其分发防止过期文件被误用，若因任何原因而保留时，需对其进行适当的标识文档管理流程根据现有的状态，文档的管理流程仅涉及归档及发布，如下图所示：说明：由作者或相应负责人提出归档申请，必须是评审通过且修改后的文档方可提出归档申请是否及时归档的检查在各个过程中的检查清单中进行检查文档作废：文档归档发布后，需同时作废此文档之前的相应版本。每次进行归档后，由归档人员统一进行文档更新发布归档之后的文档如有再更新的需求，则从基线库取出来进行更新后，重新归档。质量度量：制定项目评估项质量度量主要针对项目进行评估，从项目的计划、过程、质量、成本、客户满意度不同维度进行评估。具体细节如下。计划评估计划评估主要根据计划历史变更记录来评估计划的正确、合理性、可实施情况，并为以后的计划制定提供参考数据。主要针对里程碑进行评估，对于非里程碑的计划变化不进行评估。评估基准1．项目启动时的《项目总体计划》、每次变更后的项目计划、项目结束时的《项目总体计划》2．项目变动记录文件评估项评估项第x次变更变更原因与上次偏离率%与初始偏离率%计划变更里程碑1里程碑2里程碑3……总结1．计划变更的主要原因是什么？比如项目计划不够详细，工作安排不够细致，时间浪费对项目的技术、工作量等认识不清，导致计划时间失误对项目人员的工作效率、特长认识不清，导致计划时间失误项目任务跟踪不及时，错过最佳调整时机过程评估过程评估是根据项目的每个阶段的质量指导方针以及检查结果来进行的评估，用于检查各项目的过程控制是否达到应有的要求。过程评估最终使用计分的方式来得出过程得分。输入条件每个过程的每次的《过程检查清单》评估记录表评估记录表根据对不同阶段的关注不同，定出相应的百分比，以及每个阶段中不同评估项的重点不同，给予不同的分值，最终统计出对过程的总体评分。过程评估项评估结果最后得分单项分*百分比有(√)没有(×)N/A计划阶段25%项目总体计划（40分）是否进行总体计划评审（25分）评审是否有效（发现总体问题的60%以上的评审称之为有效）（35分）需求阶段25%需求规格说明书（40分）是否进行了需求评审（30分）评审是否有效在测试阶段发现的需求问题少于总问题数的5%（30分）设计阶段20%具有方案、概要（详细）设计文档（35分）是否进行设计评审（15分）有否原型设计（20分）是否进行过原型评审（15分）评审是否有效？（如在测试阶段发现的UE问题少于总问题数的5%）（15分）开发阶段15%是否进行单元测试（25分）单元测试是否有效--发现的问题数达到测试阶段的问题数10%或以上（15分）是否进行联调（30分）联调是否有效--发现的问题数达到测试阶段的问题数的10%或以上（20分）测试阶段15%有否测试计划或测试用例（40分）是否进行评审？（20分）评审是否有效？--发现问题数为用例总数的10%以上（15分）评审是否有效--用例发现BUG率达90%以上（25分）总计计分准则：有则加分，没有则不加分，N/A则不计算此项；当统计结果中存在不适用此项时，则统计结果需要按100分再进行一次转换；例如测试阶段分别统计为：1有；2无；3N/A，4有；则测试阶段的得分为：（40+25）/（40+20+25）*100*15%；总结对过程得出的最终分进行分析：哪些过程存在严重的质量问题？哪些过程缺乏哪些质量控制环节？哪些质量控制环节没有起到相应的作用？项目质量评估质量评估主要根据测试结果的质量评估以及现网问题跟踪情况进行的评估。输入条件1．《版本质量评估报告》2．现网问题跟踪表评估项测试阶段评估主要依据测试各类数据根据质量评估标准进行质量评估。维护阶段评估主要根据现网问题清单对缺陷率、平均缺陷时间来进行质量评估缺陷率：指现网问题数/总问题率平均缺陷时间（MTF）：指平均多久时间反馈一个问题。平均缺陷恢复时间：指出现一个缺陷后，恢复所需要的时间。评估项评估结果备注测试阶段（单版本质量评估）第一次第二次第三次维护阶段评估缺陷率其它统计平均缺陷时间缺陷恢复时间缺陷修复时间缺陷细分需求问题/所有现网问题比率功能问题/所有现网问题比率UE问题/所有现网问题比率其它问题/所有现网问题比率总结对质量情况得出来的评估结果进行分析。测试结果反馈情况主要是哪些环节中的问题现网问题反馈情况主要是哪些环节中的问题测试结果反馈情况与现网问题反映结果是否一致通过以上总结分析出哪个阶段所存在的问题最多，测试方法/策略是否存在问题；改善明确存在问题的环节。成本评估成本评估主要用于评估在各阶段的成本投入比较是否合理，质量控制成本投入是否合理，是否存在成本的浪费等情况。输入条件项目初始时的《项目总体计划》项目结束时的《项目总体计划》、《项目开发计划》、《测试计划》评估项计划成本指花费在计划环节中所费的成本，根据最终的项目总体计划统计需求阶段的成本需求成本指花费在需求环节所费的成本；根据最终的项目总体计划统计需求阶段的的成本设计成本指花费在设计环节所费的成本；包括概要设计、原型设计、详细设计等内容的工作成本。开发成本指纯开发阶段所费的成本。质量成本统计所有因质量活动而引发的成本，分好成本、坏成本，好的成本包括各预防性的质量控制，如评审、质量检查、测试；坏的成本指各种返修成本。好质量成本评审所有活动的成本测试所有活动的成本培训等支出的费用坏质量成本各种评审后的返修的成本测试之后的所有回归修改成本其它成本非以上成本之外的其它成本，包括其它的一些管理活动、沟通、协调等成本。评估项人/日占总体的%与初始计划相比（增加或减少的%）简析计划成本需求成本设计成本开发成本质量成本好质量成本坏质量成本其它成本总计总结通过以上数据结合其它评估结果分析在各阶段投入的成本是否合理，哪些成本是可以通过合理的调整来避免的，哪些成本投入应该增加。客户满意度评估客户满意度评估主要是由用服协助通过客户满意度调查结果、意见反馈单得到的数据而进行的评估。输入条件《客户满意度调查结果》、《意见反馈表》评估项评估项评估结果简析客户满意度质量目标1满意度质量目标2满意度质量目标3满意度……非质量目标满意度客户支持要求支持的次数支持的时间总结客户对非质量目标的满意度高于质量目标：质量保证与控制手段对质量目标未起到作用？客户对质量目标不关注，更关注非质量目标：质量目标定义不合理？客户要求支持的次数过多：客户总要求我方支持，是否可理解性过差？客户要求支持的时间过长：每次支持的时间过长，是否可维护性过差质量改进质量改进整个质量管理中最后的一个环节，也是一个新的质量管理实施的基础。质量改进环节主要根据项目评估结果，去分析现存在的质量问题及针对问题找出相应的质量改进措施。现存在的质量问题在每个项目告一阶段后，分析整理现在各项目中普遍存在的质量问题，区分主观问题及客观问题；并对存在的质量问题进行原因分析。问题所在阶段类型（主观/客观）原因分析质量改进措施针对提练出来的质量问题，提出改进措施，并在新项目的质量管理环节中实施，跟进实施的效果。问题XXXX产生原因分析具体产生该问题的原因分析及结论预防措施针对问题的有效预防措施附录一：评审过程检查表评审作为质量保障的重要手段之一，故针对评审过程本身，我们也可以制定一套检查表，以检验项目过程中的评审开展的成熟度。项目名称项目编号软件项目经理项目阶段评审内容被评内容的规模评审组织部门评审方式评审日期参加评审的人员评审会议时间长度（会议）评审工作量个人评审时间总计（会签）发现各类问题数报告人日期内容是否不确定不适用注释评审准备评审是否按计划进行的评审准备时间是否充分评审资料是否提供？是否完整？资料是否符合基本要求评审人员的选择是否合适评审选择的方式是否合适评审过程评审是否全面，符合要求评审人员是否提前发现了问题评审过程是否公平，没有压力对于小组评审，是否有质量保证人员监督是否形成书面评审报告评审跟踪评审的问题是否安排人员解决评审问题是否得到解决软件项目经理是否跟踪问题解决审核签字角色姓名签字日期软件项目经理研发总监附录二：参照及依从的规范文档清单编写本文档时，同时借鉴或引用研发部已发布的规章制度或模板，具体清单如下表所示。序文档类型文档名称制定部门最后发布日期存放路径公共类《研发过程管理制度规定—版本管理规定》研发部/质量组200OA-公共事务-个人文档夹-文档中心-公司文档/研发制度《项目内部评审说明书》研发部/研发管理2007-07-19OA-公共事务-个人文档夹-文档中心-公司文档/研发制度计划阶段《项目总体计划模板》研发部/研发管理2007-11-21OA-公共事务-个人文档夹-文档中心-公司文档/研发制度《项目总体计划制定指导书》研发部/研发管理需求阶段《需求规格说明书》研发部/研发管理2007-12-27《需求规格说明书编写指导》设计阶段开发阶段测试阶段《测试流程》研发部/质量组2007-12-28OA-公共事务-个人文档夹-文档中心-研发文档/流程文档《测试计划模板》研发部/质量组内部使用《测试用例编写指导》研发部/质量组内部使用《缺陷跟踪控制流程》研发部/质量组2007-12-28OA-公共事务-个人文档夹-文档中心-研发文档/流程文档《测试报告编写指导》研发部/质量组内部使用《测试报告模板》研发部/质量组内部使用《软件质量评估参照标准》研发部/质量组2009-6-2OA-公共事务-个人文档夹-文档中心-研发文档/规范文档维护阶段《现网问题跟踪流程》研发部/质量组2009-11-24OA-公共事务-个人文档夹-文档中心-公司文档/研发制度质量管理手册HUAWEIQUALITYMANAGEMENTMANUAL目录TOC\o"1-2"\h\z\u第1章质量手册说明4第2章公司愿景、使命与战略52.1愿景52.2使命52.3战略5第3章质量方针6第4章质量目标及策略74.1质量管理体系愿景74.2质量管理体系中长期目标和规划74.3质量措施和方法7第5章体系架构85.1质量管理业务总览85.2质量管理组织架构9第6章综合质量管理106.1客户满意管理106.2领导重视和全员参与106.3体系文件管理116.4质量体系规划管理126.5质量度量管理126.6内部审核和外部审核146.7管理评审146.8员工培训156.9关键资源管理166.10持续改进166.11客户财产管理18第7章产品实现过程质量管理197.1产品需求管理197.2市场管理197.3销售管理207.4产品开发207.5供应链管理227.6客户服务26第8章附录298.1华为简介298.2华为公司组织结构图298.3TL9000质量管理体系要求条文与业务描述的关系对照表308.4TL9000质量管理体系要求条文与功能系统的关系对照表318.5质量手册参考的流程文件清单318.6术语与缩略328.7手册历史33质量手册说明华为质量管理体系是依据ISO9001:2000国际质量管理标准和TL9000R4.0国际质量管理标准建立和实施的。ISO9001:2000和TL9000R4.0标准同时适用于华为的全系列产品的设计、开发、制造、销售、安装和服务的质量管理，包括数字程控交换机系列产品、宽带网络产品、NGN产品、综合业务接入设备、固定网络终端产品、光网络系列产品、无线通信网络和终端系列产品、多媒体产品、数据通信产品、业务与软件产品等。本手册是华为内部对产品和服务质量有影响的所有人员遵循的纲领性文件，对外则作为华为向客户及第三方提供产品和服务质量保证的依据。本手册引用标准：ISO9001:2000《质量管理体系要求》ISO9000:2000《质量管理体系基础和术语》<<TL9000质量管理体系要求手册4.0>><<TL9000质量管理体系测量手册4.0>>公司愿景、使命与战略2.1愿景丰富人们的沟通和生活。2.2使命聚焦客户关注的挑战和压力;提供有竞争力的通信解决方案和服务;持续为客户创造最大价值。2.3战略•为客户服务是华为存在的唯一理由,客户需求是华为发展的原动力。•质量好、服务好、运作成本低，优先满足客户需求，提升客户竞争力和赢利能力。•持续管理变革，实现高效的流程化运作，确保端到端的优质交付。•与友商共同发展，既是竞争对手，也是合作伙伴，共同创造良好的生存空间，共享价值链的利益。质量方针积极倾听客户需求；精心构建产品质量；真诚提供满意服务；时刻铭记为客户服务是我们存在的唯一理由。质量目标及策略质量管理体系愿景树立以客户为中心、全员参与的质量文化，构筑优质的产品和服务，持续改进，追求卓越，成为业界最佳。质量管理体系中长期目标和规划瞄准业界最佳，倾听、理解和满足客户需求，持续提升客户满意度。提高全流程质量能力，一次把事情做好，降低质量损失成本，增加公司利润。持续推动质量管理在公司全业务、全流程、全地域的贯通，并实现与客户流程的无缝对接，逐步构建完整、高效、全球化的端到端质量管理体系架构。在保证卓越的产品质量的前提下追求零偏差交付，力争达到业界最佳的项目周期和产品可用度。质量措施和方法在公司范围内全面深入推行、有效落实TL9000体系要求，在流程体系上确保质量活动融入到市场、研发、供应链和技术服务等各领域业务，并且实现全流程端到端贯通，同时通过实现指标数据的可收集、可分析和可应用，瞄准业界最佳Benchmark，持续推动业务改进，实现公司与客户共同的最佳绩效。全面推行、有效执行MM、OR流程，质量组织和业务延伸到市场前端、驻外地区部，加强产品前端环节的质量管理，确保质量在源头上得到保证。深入夯实IPD和CMMI流程的执行。在流程中清晰地定义产品级、项目级的质量控制和质量保证活动，对每个活动、每个阶段明确严格的进入和退出准则，严格执行检视、评审和审计等活动，实施高质量的设计和开发。同时在设计阶段就充分考虑可制造性、可服务性等需求，确保产品全流程质量。通过ISC的运作，在供应商到客户的采购、制造、发货等各个中间环节，通过完备的质量控制活动、成熟的工艺和装备技术、优良的生产设备，实施完整的供应链计划.在制造全过程中设立质量控制点，包括IQC、IPQC、PQC、FQC和OQC等，同时定期对检验能力进行评估、改进，动态调整检验方式，确保向客户提供卓越的品质、及时和柔性的供应交付。通过客户服务流程的运作，在服务流程中的各个环节全面建立相应的质量控制点，制订完整的项目计划来实施工程安装的质量保证和风险管理；在全球建立三级客户支持系统，建立800号24小时客户热线，向客户提供对问题快速的响应和优质的服务。在公司各业务领域、各产品线建立一支专门的质量工程师队伍，负责产品全过程的质量计划、质量控制和质量保证活动，同时带动业务人员，利用内部评审和专项审计、6Sigma、根因分析和SPC控制等各种手段和方法，全员开展纠正、预防和持续改进工作。充分调动和利用公司各级相关平台，通过质量专刊宣传、中基层质量培训、中高层质量专题研讨、部门宣传专栏和内部满意度调查等形式，强化全员参与和持续改进的质量意识，并通过公司质量奖评选和产品质量通报等各种质量激励活动，在公司范围内树立结果导向的质量文化。体系架构质量管理业务总览华为业务流程架构核心业务领域包括：战略规划与市场(Marketing)、集成产品开发(IPD)、客户关系管理（CRM,含CS非工程实施部分）和集成供应链（ISC，含CS的工程实施部分）；华为的质量管理活动已有效地融入到了各主要业务流程当中.5.1.1战略规划与Marketing业务中，为了确保客户的需求及时满足，华为对需求建立了跟踪机制，并在实现活动完毕后增加了对需求实现的验证；对制定出来的业务计划，5.1.2IPD业务中，华为设立有四个决策评审点和七个技术评审点。开发各阶段有评审和测试活动，确保产品开发成功。在生命周期管理阶段，收集网上反馈的问题，及时分析改进，使产品充分5.1.3在CRM管理中,华为的宣传介绍材料须经过正式的开发和评审，确保产品描述准确无误。在招投标上华为采用项目管理的方式，确保方案的准确性和承诺的可行性。5.1.4ISC业务中，华为对供应商进行认证和管理，并对采购原材料进行检验,来保证生产原材料的质量。在生产制造过程中，在线检验、设备自动化检测、组装检验和包装发货检验等确保了产品制造质量和交付质量。5.1.5除了对具体业务进行质量管理外，华为还对整个质量体系的充分性、有效性和适宜性进行管理，包括进行质量体系的内部审计、外部审计、管理评审活动，包括传递5.2质量管理组织架构5.2.1各业务部门质量管理部和产品线质量管理部对各自领域的质量管理负责；Marketing业务和市场业务的质量管理，由其运作管理办公室负责；5.2.2为了更好地管理质量，有效解决跨部门的质量问题、及时共享跨产品的质量管理经验和教训，确保华为质量管理体系持续改进，华为成立了由公司质量管理部主管、各产品线质量部主管和功能部门质量部主管组成的质量管理团队QMT。质量管理团队每月会定期召开会议，对重大质量问题进行决策,5.2.3质量管理团队的领导是华为公司的首席质量官，也是质量管理者代表综合质量管理客户满意管理华为认为,客户满意就是充分理解客户的需求并及时有效地满足、甚至超越客户的需求。华为通过以下5个方面的工作来满足客户需求:(1)客户需求收集。(2)客户需求分析/分配。(3)客户需求实施。(4)客户需求验证。(5)客户需求绩效管理。公司每年与国际专业咨询公司合作，开展第三方客户满意度调查工作。满意度调查的内容覆盖产品质量、售前支持服务、交付、工程安装、维护、培训和备件维修等各个方面。分析结果按照不同的方式、范围、内容发给各业务部门、区域机构、公司各级员工,并纳入公司高层领导的考核指标当中,同时要求各业务部门或各区域机构制定下次调查满意度目标值，认真研究调查结果，制定合理措施，以保证目标值的达成。领导重视和全员参与高层管理人员的首要责任，是要为企业创立明确的发展目标和确定努力的方向，并使这一目标和方向为全体员工所理解，坚定不移地实现这些目标。领导重视华为高层管理者对质量体系建设的重视体现在如下方面:.1制定公司的质量方针。.2任命质量管理者代表，代表公司高层行使管理质量的权责：a)确保质量管理体系所需的过程得到建立、实施和保持；b)向最高管理者报告质量管理体系的业绩和任何改进的需求；c)确保在整个组织内提高满足客户要求的意识；d)就质量管理体系有关事宜与外部联络。.3组织制定质量目标，并将关键的质量指标增加到了公司各层管理者的PBC（个人绩效承诺）考核中。.4对质量管理体系进行管理评审，以确保其持续的适宜性、完整性和有效性。.5建立必要的质量管理团队和部门来分层、分业务、分产品管理质量，并为各种有效的质量改进项目提供人、财、物的支持；并亲自参与到重大的质量改进项目中。全员参与华为公司的质量管理是通过组织内各职能各层级人员参与产品实现及支持过程来实施的。过程的有效性直接取决于公司各级人员的意识、能力和主动精神。华为公司从高层到基层，全体员工都应参与到全面质量管理当中，如下示意图：对于公司高层领导，主要通过指标/目标来牵引，使其积极参与到质量改善活动中去；对于中层干部，起着承上启下的作用,一方面要落实公司高层的任务，承担分解的指标/目标，另一方面要发动组织基层员工进行改进，通过专项质量改进（攻关）、6Sigma活动等,不断地改进产品质量过程质量；对于基层员工，公司强调立足于本岗位，点滴改进，“小改进，大奖励”，通过合理建议,品管圈(QCC）等活动，引导员工自发进行质量的改进。体系文件管理华为的质量管理体系文件以金字塔的形状进行组织。最上层的是华为质量方针；第二层是质量管理手册和业务流程框架；第三层是各业务领域的流程和支持流程运作的指导书、标准、规范、模板、表单等；最下层是流程运作的结果记录。华为将第三层的流程和其支撑流程的文件统称为流程文件。质量方针和质量手册华为的质量方针纳入质量手册，作为对质量体系建设的纲要；质量手册则对照ISO9001:2000和TL9000质量管理体系标准的要求，明确质量目标、质量策略、质量业务框架，以及具体各业务质量的管理原则和方法，作为对质量体系建设的指导和业务开展的具体要求。文件控制华为流程文件的拟制、修订和发布严格按照«华为公司流程管理手册»的要求进行操作。在IT数据库的支持下，流程文件实现在线评审、发布、搜索、升级和作废。所有流程文件发布之前经过相关部门主管(Stakeholder)的评审，最后经过流程责任人的批准后发布。公司质量管理部每年组织各业务部门对流程文件进行审视，保证流程文件的充分与适宜。对从客户、供应商等获取的外部文件和数据按照«华为公司流程管理手册»进行识别和标示，并在相应的业务流程中定义具体管理方法。华为公司的技术文档根据其类别由不同的部门负责管理。产品技术文档通过PDM系统进行管理；生产作业、设备管理等技术类文件，严格按照《供应链技术文件管理流程》的要求进行管理。公司每年组织至少一次全面的流程审视工作,以确保流程的规范性和有效性。记录控制华为《记录控制流程》定义和明确各类质量、环境、职业健康和安全记录的标识、储存、保护、检索和处置的原则。具体记录的控制和保存方法必须在各流程文件中定义清楚。质量体系规划管理6.4.1质量跨产品线或功能领域的质量改进项目由公司质量管理团队统一规划。各产品线、功能领域负责规划本领域的质量管理工作在本产品线或功能领域评审通过，也要求提交公司质量管理团队评审。质量规划分为年度规划和年中审视两部分.在质量体系的规划中,华为将客户需求和供应商需求做为质量体系规划输入的一部分，通过客户关系管理流程调查和了解客户的需求,通过供应商认证,新物料选型等相关流程了解供方需求。6.4公司质量管理团队、产品线质量部门和各功能领域每年年初完成年度质量规划。公司质量管理团队年度规划输入材料包括，但不限于：a)公司质量管理团队KPI目标完成情况；b)公司客户满意度调查结果；c)网上问题趋势分析；d)年度规划项目完成情况；e)质量管理团队月度例会遗留问题完成情况；f)公司总体经营策略、IRB制定的策略和方向;公司质量管理团队年度规划输出公司质量管理团队质量工作总结和工作规划。产品线或功能部门年度规划输入材料包括，但不限于:a)公司质量管理团队年度工作重点；b)产品线或部门质量KPI目标完成情况；c)网上问题趋势分析；d)年度规划重点工作完成情况；e)公司总体经营策略、产品线或功能部门策略和方向;产品线或功能部门年度规划输出各产品线或功能部门质量工作总结和工作规划。6.4公司质量管理部在年中组织各产品线和功能部门进行年中工作总结，并根据实际情况调整年度工作规划，公司质量管理部及时更新重点工作跟踪计划。质量度量管理6.5公司质量测评体系架构参加下面示意图：第一层是客户满意度指标；第二层指标是反映产品应用、技术服务、生产交付三个方面全流程的结果指标，支持客户满意度指标的提升和改进；第三层是针对各业务过程的指