2022年XX项目质量控制管理方案.docx

《2022年XX项目质量控制管理方案.docx》由会员分享，可在线阅读，更多相关《2022年XX项目质量控制管理方案.docx（19页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、工程质量管控方案1 工程质量管控方案1.1 前言1.1.1 目的本方案的目的在于对所开发的软件规定各种必要的质量保证措施，以保证所交付的软件能够满意工程预定需求，能够满意本工程总体组制定的且经领导小组评审批准的该软件系统需求规格说明书中规定的各项具体需求；软件开发工程组在开发软件系统所属的各个子系统（其中包括为本工程研发或选用的各种支持软件、组件）时，都应当执行本方案中的有关规定，但可依据各自的情形对本方案作适当的剪裁，以满意特定的质量保证要求，剪裁后的方案必需经工程组相关负责人批准；1.1.2 术语和定义1、质量治理：在质量方面指挥和掌握组织的和谐活动2、质量策划：质量治理的一部分，致力于制

2、定质量目标并规定必要的运行过程3、和相关资源以实现质量目标4、质量掌握：质量治理的一部分，致力于满意质量要求5、质量保证：质量治理的一部分，致力于供应质量要求会得到满意的信任6、质量度量：质量治理的一部分，致力于对已存在的质量数据进行分析，得出当前质量治理结果的评估数据；7、质量改进：质量治理的一部分，致力于增强满意质量要求的才能1.2 质量方案：制定新工程及保护性工程质量方案在本环节中，依据工程的规模及性质进行质量策划，制定本工程的质量方案；为后续的质量掌握、质量评估及质量改进做出行动纲领；针对公司主要有新工程及保护性工程两类版本，且两者之间的质量投入有所差异的特性，故质量方案可以区分以下：

3、1.2.1 常规工程质量方案要求常规工程的质量方案制定按质量要求分析/ 质量目标 / 人员. 职责及质量保证、过程检查方案组成，各项的具体要求如下所述；1.2.1.1 质量要素分析1. 主要的质量要性如下：功能性质量因素：正确性，健壮性，牢靠性非功能性质量因素：性能，易用性，清晰性，安全性，可扩展性，兼容性，可移植性其它质量因素：非以上要求之外的要求；2. 依据产品的特性及市场目标，将关键的质量要素确认，同时区分本工程的类型倾质量型工程：指本工程对质量掌握更关注倾成本型工程：指本工程对成本掌握更关注倾工期型工程：指本工程对工期要求更关注依据以上分析，再制定相应的质量目标；1.2.1.2 质量目

4、标订立质量目标时，一般遵循 SMART原就 S：specific具体的M：measurable 可测量的A：achievable可取得的R：realistic切实的T：timely准时的依据以上原就，我们可以制定如下质量目标：1. 比如本工程的质量要素为功能正确性、功能健壮性、性能那质量目标可定义例下：需求中所定义的功能都得以实现不稳固问题（等级非稍微）都被解决关键模块（模块名称）的性能不能低于V1.0 版本2. 针对质量目标定出优先级1、3、23. 目标分解分解为阶段质量目标完成阶段质量目标的手段1.2.1.3 人员与职责参与质量治理活动的人员，一般情形下，工程组全部的人都可以参与到质量治理

5、活动中来；但我们一般可定义如下人员去分别承担相应的职责；1. 质量治理人员：制定质量治理方案，对质量过程进行掌握；对过程检查单进行实施；进行质量度量，制定质量改进方案及实施；参与各类评审活动；2. 测试人员：制定测试方案，对工程进行测试，进行测试结果的度量分析；参与各类评审活动；3. 工程治理人员：帮助组织解决质量治理过程中所发觉的各类问题及风险；1.2.1.4 质量保证方案依据当前的质量目标，方案需要进行哪些质量保证工作，一般可包括专业培训、同级评审、测试；1.2.1.4.1 培训1. 确认是否需要培训2. 确认培训的内容、人员、时间，以及所耗费的资源；1.2.1.4.2 评审1. 确认评审

6、内容及方案；需要包括评审的内容、评审的方式以及评审的人员等等；2. 对评审结果的跟踪、治理方式；1.2.1.4.3 测试1. 依据当前的质量目标，确定测试的初步方案，包括测试的范畴及测试方法、手段以及投入的人力准时间资源1.2.1.5 过程检查方案依据当前的质量目标，制定工程过程中需要检查的对象、例如：阶段检查对象检查时机次数检查执行人员检查依据计划阶计 划 阶 段 的工程 组成立之3 次对应 测试 接口依据 方案 阶段检查段产出后至 方案阶段终止人清单进行检查需求阶需求评审需求评审启动1 次对应 测试 接口依据 需求 阶段检查段人清单进行检查；1.2.2 保护性工程质量方案要求保护性工程的质

7、量方案制定相对简洁，不需要花较多的时间在其上，并且可以套用比较固定的模板；保护性工程基本上会有很明确的需求点以及具体的时间点要求，一般情形下，保护时期会很长，且需求相对较散、小，针对这些特性，保护性工程的质量方案要求仅可以包括：质量目标、质量保证方案、过程检查方案；1.2.2.1 质量目标依据当前的需求简洁定出本版本的质量目标；1.2.2.2 质量保证方案在保护性工程中，质量保证方案主要包括：需求争论、联调以及测试；需求争论：参与人员包括开发及测试人员；需求争论结果报告联调：对所做的修改及周边进行联调；联调测试报告测试：依据质量目标制定相应的测试方案支配，1.2.2.3 过程检查方案无论质量目

8、标定为如何，保护性工程的过程检查，仅需要如下环节： 需求争论会：是否进行了需求争论会，需求争论会的与会人员及结果联调：是否进行了联调，对原版本的影响测试执行：对测试过程进行检查1.3 质量保证与掌握质量保证与掌握是质量治理中最重要的一个环节，质量目标是否能够有效的实现都有赖于此环节的实施掌握；本环节依据质量保证方案、过程检查方案对版本开发的各过程定出质量指导方针、评审环节规章以及检查清单；其中质量指导方针 ：用于简要指引如何高质量的完成本阶段的工作评审治理 ：主要制定简洁的评审输入、输出以及该阶段评审的基本准就任务检查单： 用于检查该阶段的任务是否进行以及进行的成效如何常存在的问题 ：更多的是

9、让各成员明白一些体会所谈会存在哪些问题，可提前预防或纠正1.3.1 方案阶段方案阶段指从工程启动至工程总体方案制定完成的阶段；1.3.1.1 质量指导方针在工程的方案阶段，期望产出高质量的工程总体方案，建议遵守以下原就：1. 依据工程总体方案模板、工程总体方案编制说明书的指导原就进行方案编排2. 方案制定时需结合实际并与相关人员进行必要的沟通3. 明白工程背景、工程目标以及可调动的资源等4. 方案制定时需考虑相应风险及应对措施：如人员变动、需求变化、技术难题5. 对于把控不准的工程进行不同层面的评审1.3.1.2 评审治理方案阶段的评审主要指工程总体方案的评审；1.3.1.2.1 评审输入项工

10、程总体方案以及当前工程原始需求等相关资料1.3.1.2.2 评审准就评审项评审要求备注工程总体方案的评审主要从完整性、正确性、合理性、可治理性进行评审；完整性1.是否包括从需求至发布各个阶段的任务方案？2.是否对各任务的交付件定义了质量要求？正确性1.各阶段定义是否正确？2.各子任务所属的阶段是否正确？合理性1.各个任务的先后次序是否合理？并串行支配是否合理？2.各任务安排的资源是否合理？3.各任务细化的程度是否合理？4.任务与任务之间的约束是否合理？5.各阶段的时间投入比例是否合理？6.工程的终止时间，是否与客户承诺的一样7.工程的方案中是否考虑一些常见的风险？8.对风险的应对是否表达在方案

11、中？可治理性1.对于每个阶段是否有明确的里程碑大事？2.里程碑是否有明确、可衡量的目标？评审项评审要求里程碑达到时，是否能供应标志阶段终止的正式输出文档？备注3.1.3.1.2.3 评审输出评审结果输出包括：1. 评审结果记录表1.3.2 需求阶段需求阶段指从需求猎取至输出需求规格说明书阶段；需求阶段可划分为：猎取需求、分析需求、编写需求规格说明书三个阶段；1. 猎取需求 ：主要从编写工程视图与范畴、用户群分类、挑选产品/ 工程需求代表、确定使用实例、分析工作流程、需求重用这几步骤进行2. 分析需求 ：包括绘制关联图、创建开发原型、分析可行性、划分需求优先级；3. 编写需求规范说明书 ：依据工

12、程特点裁剪模板、猎取功能和技术需求、注明需求来源、开发需求追踪矩阵；1.3.2.1 质量指导方针依据需求模板、需求编写指导说明书制定需求说明文档需求文档中应包括明确的需求范畴需求文档中应包括主要的质量属性需求需细化到要求的程度（可以依据需求进行开发设计及测试设计） 需求的不确定项不超过总体需求的5%需求中应明确定义需求的优先级制定需求治理原就（包括需求标识、跟踪方式、变更掌握原就）1.3.2.2 评审治理需求阶段评审主要针对需求的清晰性、正确性、完整性、可治理性进行评审；评审的形式按实际的质量方案中要求而定；1.3.2.2.1 评审输入项技术方案建议书、需求分析、需求规格说明书1.3.2.2.

13、2 评审准就需求评审时，主要针对需求的清晰性、正确性、完整性、可行性、可治理性进行评审， 评审细项如下图所示：评审项评审要求备注1 清 晰1.系统的目标是否已定义？性2.是否对关键术语及略缩语进行了定义？3.是否有对整套系统进行了功能概述？2 正 确1.需求与需求之间是否有重复或冲突 .性2.本需求说明书与相关需求素材是否一样？3.是否清晰、简洁、无二义地表达了每个需求.4.是否每个需求都在工程的范畴内5.是否每个需求都没有内容和语法上的错误.3 完 整性4 可 行性5 可 治理性1. 编写的全部需求，其具体程度是否一样和合适.2. 需求是否能为设计供应足够的基础 .3. 全部对其他需求的内部

14、引用是否正确 .4. 是否已经列出了系统所必要的依靠 / 假设以及约束5. 是否包含了全部已知的客户需求或系统需求.6. 是否已经对每个业务规律进行输入、输出以及过程的具体说明7. 是否已具体说明白软件环境（共存的软件）和硬件环境（特定的配置）8. 是否遗漏了必要的信息 .假如有遗漏的话 , 把他们标记为待确定的问题TBD .9. 是否包括了主要的质量属性，例如性能要求、安全性要求、牢靠性要求、可复原性要求、稳固性要求等等10. 是否分析了潜在的需求11. 是否标识并解决了需求中的潜城的问题1. 所描述的全部功能是否都必要？2. 所描述的全部功能是否充分的满意客户/ 系统目标？3. 已知的限制

15、（局限）是否已经具体说明？4. 是否已经确定每个需求的实现优先级 .5. 在现有的资源内 ,是否能实现全部的需求 .6. 是否每个需求都可以进行验证（测试）？1. 是否将需求分别陈述，因此它们是独立的并且是可检查的？2. 是否全部需求都可以回溯到相应的需求素材，反之亦然？3. 是否已具体说明需求变更的过程？一样性1.是否存在冲突或重复的需求项2. 开发方案 / 产品和活动和需求是否保持一样3. 是否可以依据软件需求规范中的信息制定出具体的测试集，并且评审项评审要求备注每项需求是否可以测试4.是否有需求跟踪矩阵1.3.2.2.3 评审输出1. 评审结果清单2. 依据评审修订后的需求规格说明书1.

16、3.3 设计阶段设计阶段包括技术方案形成、概要设计、原型设计、具体设计（假如有的话）等工作的完成；1.3.3.1 质量指导方针1. 依据概要设计文档模板要求及需求剪裁适合当前工程的模板2. 依据模板编写概要设计说明书3. 对于质量方案中的关键质量属性在设计中需要重点考虑4. 需要针对工程的结构、工程的特点和用户的需求来分析，同样也要考虑到参与工程小组成员的素养5. 对于不同的方案分别进行评估6. 对概要设计文档进行同行评审7. 在设计阶段同时完成原型的设计8. 依据实际需要考虑是否需要进行具体设计9. 涉及到的需求变更需同步知会其它环节的更新；1.3.3.2 评审治理在设计阶段需要对设计实现方

17、案、设计、原型等进行评审；评审的形式按实际的质量方案中要求而定；以下仅供应概要设计说明的评审准就1.3.3.2.1 评审输入项概要设计说明书，需求规格说明书1.3.3.2.2 评审准就评审项评审要求概要设计说明书评审准就正确性1.设计说明书的编写是否依据标准模板来编写.2.设计是否正确？是否能够满意需求？ 可行性3.设计方案在现有条件下是否可行？ 可懂得性4.设计方案是否能被相关人员懂得？ 完整性5.是否包括核心功能的实现方案？6. 全部的功能需求与非功能需求是否都表达在了设计中？7. 在设计中是否增加了不必要的功能？8. 是否为将来的变更进行了过渡设计？9. 各子系统、模块之间的关系是否描述

18、得清晰10. 系统的设计是否考虑了系统的可扩展性11. 设计是否考虑了重用性12. 重用构件是否进行了标识13. 是否说明白重用模块的猎取方式和相关的文档14. 系统的设计是否考虑了系统的易移植性15. 设计是否使用标准的技术，防止使用怪异的、不易懂得的方式和方法16. 设计的调用宽度、调用深度、耦合度、内聚度和结构化程度是否进行了描述可追溯性17.设计是否可以跟踪到需求18.需求是否可以追溯到设计1.3.3.2.3 评审输出评审结果列表、评审修订后的概要设计文档1.3.4 开发阶段开发阶段主要从代码规范、代码走查、调测等进行掌握治理；1.3.4.1 质量指导方针1. 商定开发的编码规范2.

19、商定代码审计所需的时间及规章3. 商定开发阶段的调测方式4. 商定开发阶段自测的标准5. 商定提交版本提交的原就1.3.4.2 代码走查走查项走查要求备注规范性编码是否符合工程或组织的编码标准头文件包含是否完整参数在程度开头时是否被初始化参数在循环开头时是否被初始化在承数或过程调用的时候参数是否被初始化函数调用的格式和参数是否正确变量的声明和拼写是否一样变量声明的范畴是否恰当是否全部的指针都被初始化为 NULL 程序中申请的内存使用后是否释放 是否每个 =，| 等都验证了正确性是否打开的文件都准时关闭了1.3.5 测试阶段1.3.5.1 质量指导方针1. 尽早的介入测试，全部的测试都可以追溯到

20、需求2. 在测试相应方案启动之前，必需先懂得且分析需求3. 依据质量方案来制定相应的测试方案4. 测试方案中需涵盖全部关键质量属性5. 进行测试方案评审及修订6. 建立测试用例对测试需求的掩盖率7. 进行测试用例评审及修订8. 不同测试阶段可有方案的调整当前的测试重点1.3.5.2 评审治理测试评审包括测试方案、测试用例的评审，一般可分为内部评审及外部评审；评审的形式按实际的质量方案中要求而定；以下仅供应测试用例的评审准就；1.3.5.2.1 评审输入需求规格说明书、概要设计说明书、测试方案、测试用例、1.3.5.2.2 评审准就测试用例评审活动可以确保用例符合优秀用例陈述的特点，包括完整、正

21、确、可行、必 要、具有优先级、无二义性和可验证性,同时亦符合好的用例特点，即完整性、一样性、易修改和可跟踪性；评审过程保证用例满意如下要求：完整性：指有明确的目的、输入、输出，供应必要的备注信息； 正确性：指每个用例的期望结果与实际需求一样；可执行性：可执行性指测试人员依据测试用例能够独立执行测试； 代表性：指能用最简洁的数据，最简捷的路径达到测试的目的； 唯独性：指在各个测试用例没有重复交叉的现象；有效性：指每个用例是否有效？是否冗余？是否能够执行；独立性：是用例与用例之间是否互不依靠？是否能够独立执行； 可读性：指测试用例描述清晰，规律正确，拆分合理；质量指标：指是否能够满意质量指标中的掩

22、盖率要求，是否可以满意BUG密度的质量要求；内部评审准就评审项评审要求备注完整性1.针对每个测试需求，是否至少有一个正面用例，是否至少有一个以上反面用例去测试？2.针对重要测试需求，是否至少使用了两种以上的设计方法？唯独性1.是否存在重复的用例？2. 是否存在可以合并的用例？3. 是否存在需要拆分的用例？4. 是否存在冗余的用例？5. 是否存在无效的用例？独立性1.每一个用例的目的、操作过程、期望结果是否独立？2.每一个用例的目的及期望结果是否保持统一？ 期望结果是否过于发散？可读性1.不同用例之间针对相关联的内容描述是否相同？是否存在互斥、冲突的地方？2.每个测试用例是否清晰的填写了测试特性

23、、步骤、预期结果？代表性1.是否考虑到测试用例的执行效率？怎么样的步骤组合才是最高效的？2. 测试用例是否具有指导性 , 是否能敏捷指导测试人员通过用例发觉更多缺陷 , 而不是限制他们的思维外部评审准就评审项评审要求备注全面性1.用例树结构定义是否合理？2.用例是否包括如下方面：功能、界面、性能用例及需求中涉及到的其它方面用例完整性1.用例是否掩盖了全部显性的需求？用例是否掩盖了全部隐性的需求2. 针对每个测试需求，是否从正面、反面分别去验证测试需求？3. 测试用例是否掩盖每个被测功能的全部可能的输入输出的组合？4. 测试用例是否掩盖正常的输入输出组合的全部可能的取值范畴？5. 测试用例是否包

24、括测试了被测试对象的初始化过程？6. 测试用例是否包含了被测对象中全部反常流的测试？7. 是否把最多的测试用例精力放在系统的最主要功能上？8. 针对每个测试用例，是否标识了优先级，且标识合理？质量指标1. 针对每个期望用例的期望结果；对开发的要求是否合理？测试开发设计的熟悉是否一样？2. 用例期望结果理中与需求保持一样？3. 每一个用例的依靠数据、期望结果是否具体到表及字段的变化？1. 用例掩盖率是否达到相应质量指标 .2. 用例预期缺陷率是否达到相应质量指标 .1.3.5.2.3 评审输出评审结果列表评审修订通过的测试用例列表1.3.6 发布及保护阶段1.3.6.1 质量指导方针1. 依据发

25、布阶段要求预备相应的程序及文档2. 准时检查归档的各类资源3. 依据工程特性或公网情形制定现网问题跟踪流及治理方式4. 与用服结合制定软件的客户中意度调查单1.3.7 质量掌握中的文档治理质量治理睬形成除工程文档之外的治理文档，故文档治理主要为解决工程过程中产生的各类文档的正确性、唯独性、准时性、有效性所做的相应约束；1.3.7.1 文档分类(1) 开发文档：这类文档在软件工程开发过程中，表达了软件开发人员前一阶段工作的成 果，同时又是后一阶段工作的依据；这类文档包括可行性争论报告、软件工程开发方案、软件需求规格说明、系统规格说明书、软件功能说明书和数据字典等；(2) 治理文档：这类文档在软件

26、工程开发过程中，由软件开发人员制定的需提交治理部门的一些工作方案、工作方案和工作报告；通过阅读这些文档，治理人员能够明白软件工程开发活动支配、进度、资源使用等情形；这类文档包括工程开发方案、测试方案、测试方 案、开发进度报告和工程总结报告等；(3) 用户文档：这类文档是软件开发人员为使用该软件的网点经办人员预备的有关该软件产品使用、操作的资料，主要是操作手册及新功能介绍方面的文档；(4) 记录文档：与客户沟通往来的记录、软件工程开发过程中各种会议、跟踪记录、审查记录、产品投产记录和问题跟踪解决记录等；(5) 反馈文档：这类文档主要是软件产品在推广使用以后，客户对产品使用过程中看法及产品缺陷、质

27、量等方面的信息反馈；1.3.7.2 文档治理工具文档治理工具现在采纳 VSS治理方式；存放至文档基线库；文档基线库1.3.7.3 文档治理的基本要求正确性：全部的文档都使用相当的标准模板文档中所述的内容正确无误唯独性：每个版本的文档只有一个；准时性：文档随每个任务的执行能够准时编制及公布有效性：防止无效的文档归档以及过期文档被误用；具体要求：1. 全部的文档都使用相应的标准模2. 文档发布或归档前得到批准3. 必要时对文件进行定期评审与更新4. 确定文件的更换和现行修订状况得到识别5. 确保在使用时可获得有关版本的适用文件6. 确保文件保持清晰、易于识别7. 确保外部文件得到识别并掌握其分发8

28、. 防止过期文件被误用，如因任何缘由而保留时，需对其进行适当的标识1.3.7.4 文档治理流程依据现有的状态，文档的治理流程仅涉及归档及发布，如下图所示：作者提出归档申请质检人员检查文档一般，必需是评审通过且修订后的文档方提交归档申请检查文档使用的模板是否正确检查文档是否为最新检查文档是否标识了版本号/修订等信息检查是否通过纳入文档基线库关闭权限通知作者及其它相关人员说明：由作者或相应负责人提出归档申请，必需是评审通过且修改后的文档方可提出归档申请是否准时归档的检查在各个过程中的检查清单中进行检查文档作废：文档归档发布后，需同时作废此文档之前的相应版本；每次进行归档后，由归档人员统一进行文档更

29、新发布归档之后的文档如有再更新的需求，就从基线库取出来进行更新后，重新归档；1.4 质量度量：制定工程评估项质量度量主要针对工程进行评估，从工程的方案、过程、质量、成本、客户中意度不同维度进行评估；具体细节如下；1.4.1 方案评估方案评估主要依据方案历史变更记录来评估量划的正确、合理性、可实施情形，并为以后的方案制定供应参考数据；主要针对里程碑进行评估，对于非里程碑的方案变化不进行评估；1.4.1.1 评估基准1. 工程启动时的工程总体方案、每次变更后的工程方案、工程终止时的工程总体方案2. 工程变动记录文件评估项第 x 次变更变更缘由与上次偏离率%与初始偏离率%里程碑 1计划变更里程碑 2

30、里程碑 31.4.1.2 评估项1.4.1.3 总结1. 方案变更的主要缘由是什么？比如工程方案不够具体，工作支配不够细致，时间铺张对工程的技术、工作量等熟悉不清，导致方案时间失误对工程人员的工作效率、特长熟悉不清，导致方案时间失误工程任务跟踪不准时，错过正确调整时机1.4.2 过程评估过程评估是依据工程的每个阶段的质量指导方针以及检查结果来进行的评估，用于检查各工程的过程掌握是否达到应有的要求；过程评估最终使用计分的方式来得出过程得分；1.4.2.1 输入条件每个过程的每次的过程检查清单1.4.2.2 评估记录评估记录依据对不同阶段的关注不同，定出相应的百分比，以及每个阶段中不同评估项的重点

31、不同，赐予不同的分值，最终统计出对过程的总体评分；1.4.2.3 总结对过程得出的最终分进行分析：1. 哪些过程存在严峻的质量问题？2. 哪些过程缺乏哪些质量掌握环节？3. 哪些质量掌握环节没有起到相应的作用？1.4.3 工程质量评估质量评估主要依据测试结果的质量评估以及现网问题跟踪情形进行的评估；1.4.3.1 输入条件1. 版本质量评估报告2. 现网问题跟踪表1.4.3.2 评估项测试阶段评估主要依据测试各类数据依据质量评估标准进行质量评估；保护阶段评估主要依据现网问题清单对缺陷率、平均缺陷时间来进行质量评估缺陷率：指现网问题数 / 总问题率平均缺陷时间（ MTF）：指平均多久时间反馈一个

32、问题； 平均缺陷复原时间：指显现一个缺陷后，复原所需要的时间；1.4.3.3 总结对质量情形得出来的评估结果进行分析；1. 测试结果反馈情形主要是哪些环节中的问题2. 现网问题反馈情形主要是哪些环节中的问题3. 测试结果反馈情形与现网问题反映结果是否一样通过以上总结分析出哪个阶段所存在的问题最多，测试方法/ 策略是否存在问题；改善明确存在问题的环节；1.4.4 成本评估成本评估主要用于评估在各阶段的成本投入比较是否合理，质量掌握成本投入是否合理，是否存在成本的铺张等情形；1.4.4.1 输入条件1. 工程初始时的工程总体方案2. 工程终止时的工程总体方案、工程开发方案、测试方案1.4.4.2

33、评估项1. 方案成本指花费在方案环节中所费的成本，依据最终的工程总体方案统计需求阶段的成本2. 需求成本指花费在需求环节所费的成本；依据最终的工程总体方案统计需求阶段的的成本3. 设计成本指花费在设计环节所费的成本；包括概要设计、原型设计、具体设计等内容的工作成本；4. 开发成本指纯开发阶段所费的成本；5. 质量成本统计全部因质量活动而引发的成本，分好成本、坏成本，好的成本包括各预防性的质量掌握，如评审、质量检查、测试；坏的成本指各种返修成本；好质量成本1) 评审全部活动的成本2) 测试全部活动的成本3) 培训等支出的费用坏质量成本1) 各种评审后的返修的成本2) 测试之后的全部回来修改成本6

34、. 其它成本非以上成本之外的其它成本，包括其它的一些治理活动、沟通、和谐等成本；1.4.4.3 总结通过以上数据结合其它评估结果分析在各阶段投入的成本是否合理，哪些成本是可以通过合理的调整来防止的，哪些成本投入应当增加；1.4.5 客户中意度评估客户中意度评估主要是由用服帮助通过客户中意度调查结果、看法反馈单得到的数据而进行的评估；1.4.5.1 输入条件客户中意度调查结果、看法反馈表1.4.5.2 评估项评估项评估结果简析质量目标 1 中意度质量目标 2 中意度客户中意度质量目标 3 中意度非质量目标中意度要求支持的次数客户支持支持的时间1.4.5.3 总结客户对非质量目标的中意度高于质量目

35、标：质量保证与掌握手段对质量目标未起到作用？客户对质量目标不关注，更关注非质量目标：质量目标定义不合理？ 客户要求支持的次数过多：客户总要求我方支持，是否可懂得性过差？ 客户要求支持的时间过长：每次支持的时间过长，是否可保护性过差1.5 质量改进质量改进整个质量治理中最终的一个环节，也是一个新的质量治理实施的基础；质量改进环节主要依据工程评估结果，去分析现存在的质量问题及针对问题找出相应的质量改进措施；1.5.1 现存在的质量问题在每个工程告一阶段后，分析整理现在各工程中普遍存在的质量问题，区分主观问题及客观问题；并对存在的质量问题进行缘由分析；1.5.2 质量改进措施针对提练出来的质量问题，提出改进措施，并在新工程的质量治理环节中实施，跟进实施的成效；