某某项目质量控制管理实施方案

.wd.工程质量管控方案1 工程质量管控方案1.1 前言1.1.1 目的本方案的目的在于对所开发的软件规定各种必要的质量保证措施，以保证所交付的软件能够满足工程预定需求，能够满足本工程总体组制定的且经领导小组评审批准的该软件系统需求规格说明书中规定的各项具体需求。 软件开发工程组在开发软件系统所属的各个子系统其中包括为本工程研发或选用的各种支持软件、组件时，都应该执行本方案中的有关规定，但可根据各自的情况对本方案作适当的剪裁，以满足特定的质量保证要求，剪裁后的方案必须经工程组相关负责人批准。 1.1.2 术语和定义1、质量管理：在质量方面指挥和控制组织的协调活动2、质量筹划：质量管理的一局部，致力于制定质量目标并规定必要的运行过程3、和相关资源以实现质量目标4、质量控制：质量管理的一局部，致力于满足质量要求5、质量保证：质量管理的一局部，致力于提供质量要求会得到满足的信任6、质量度量：质量管理的一局部，致力于对已存在的质量数据进展分析，得出当前质量管理结果的评估数据。7、质量改进：质量管理的一局部，致力于增强满足质量要求的能力1.2 质量方案：制定新工程及维护性工程质量方案在本环节中，根据工程的规模及性质进展质量筹划，制定本工程的质量方案；为后续的质量控制、质量评估及质量改进做出行动纲领。针对公司主要有新工程及维护性工程两类版本，且两者之间的质量投入有所差异的特性，故质量方案可以区分以下：1.2.1 常规工程质量方案要求常规工程的质量方案制定按质量要求分析/质量目标/人员.职责及质量保障、过程检查方案组成，各项的具体要求如下所述。1.2.1.1 质量要素分析1. 主要的质量要性如下：n 功能性质量因素：正确性，强健性，可靠性n 非功能性质量因素：性能，易用性，清晰性，安全性，可扩展性，兼容性，可移植性n 其它质量因素：非以上要求之外的要求。2. 根据产品的特性及市场目标，将关键的质量要素确认，同时区分本工程的类型n 倾质量型工程：指本工程对质量控制更关注n 倾本钱型工程：指本工程对本钱控制更关注n 倾工期型工程：指本工程对工期要求更关注根据以上分析，再制定相应的质量目标。1.2.1.2 质量目标订立质量目标时，一般遵循SMART原那么S：specific具体的M：measurable可测量的A：achievable可取得的R：realistic切实的T：timely及时的根据以上原那么，我们可以制定如下质量目标：1. 比方本工程的质量要素为功能正确性、功能强健性、性能那质量目标可定义例下：l 需求中所定义的功能都得以实现l 不稳定问题等级非轻微都被解决l 关键模块模块名称的性能不能低于V1.0版本2. 针对质量目标定出优先级l 1、3、23. 目标分解l 分解为阶段质量目标l 完成阶段质量目标的手段1.2.1.3 人员与职责参加质量管理活动的人员，一般情况下，工程组所有的人都可以参与到质量管理活动中来。但我们一般可定义如下人员去分别承担相应的职责。1. 质量管理人员：制定质量管理方案，对质量过程进展控制；对过程检查单进展实施；进展质量度量，制定质量改进方案及实施；参与各类评审活动。2. 测试人员：制定测试方案，对工程进展测试，进展测试结果的度量分析；参与各类评审活动。3. 工程管理人员：协助组织解决质量管理过程中所发现的各类问题及不安全因素。1.2.1.4 质量保障方案根据当前的质量目标，方案需要进展哪些质量保障工作，一般可包括专业培训、同级评审、测试。1.2.1.4.1 培训1. 确认是否需要培训2. 确认培训的内容、人员、时间，以及所消耗的资源。1.2.1.4.2 评审1. 确认评审内容及方案；需要包括评审的内容、评审的方式以及评审的人员等等。2. 对评审结果的跟踪、管理方式。1.2.1.4.3 测试1. 根据当前的质量目标，确定测试的初步方案，包括测试的范围及测试方法、手段以及投入的人力及时间资源1.2.1.5 过程检查方案根据当前的质量目标，制定工程过程中需要检查的对象、例如：阶段检查对象检查时机次数检查执行人员检查依据方案阶段方案阶段的产出工程组成立之后至方案阶段完毕3次对应测试接口人根据方案阶段检查清单进展检查需求阶段需求评审需求评审启动1次对应测试接口人根据需求阶段检查清单进展检查。1.2.2 维护性工程质量方案要求维护性工程的质量方案制定相对简单，不需要花较多的时间在其上，并且可以套用比照固定的模板。维护性工程 基本上会有很明确的需求点以及具体的时间点要求，一般情况下，维护时期会很长，且需求相对较散、小，针对这些特性，维护性工程的质量方案要求仅可以包括：质量目标、质量保障方案、过程检查方案。1.2.2.1 质量目标根据当前的需求简单定出本版本的质量目标。1.2.2.2 质量保障方案在维护性工程中，质量保障方案主要包括：需求讨论、联调以及测试。需求讨论：参与人员包括开发及测试人员；需求讨论结果报告联调：对所做的修改及周边进展联调；联调测试报告测试：根据质量目标制定相应的测试方案安排，1.2.2.3 过程检查方案无论质量目标定为假设何，维护性工程的过程检查，仅需要如下环节：l 需求讨论会：是否进展了需求讨论会，需求讨论会的与会人员及结果l 联调：是否进展了联调，对原版本的影响l 测试执行：对测试过程进展检查1.3 质量保证与控制质量保证与控制是质量管理中最重要的一个环节，质量目标是否能够有效的实现都有赖于此环节的实施控制。本环节根据质量保障方案、过程检查方案对版本开发的各过程定出质量指导方针、评审环节规那么以及检查清单。其中质量指导方针：用于简要指引假设何高质量的完本钱阶段的工作评审管理：主要制定简单的评审输入、输出以及该阶段评审的 基本准那么任务检查单：用于检查该阶段的任务是否进展以及进展的效果假设何常存在的问题：更多的是让各成员了解一些经历所谈会存在哪些问题，可提前预防或纠正1.3.1 方案阶段方案阶段指从工程启动至工程总体方案制定完成的阶段。1.3.1.1 质量指导方针在工程的方案阶段，期望产出高质量的工程总体方案，建议遵守以下原那么：1. 根据?工程总体方案模板?、?工程总体方案编制说明书?的指导原那么进展方案编排2. 方案制定时需结合实际并与相关人员进展必要的沟通3. 了解工程背景、工程目标以及可调动的资源等4. 方案制定时需考虑相应不安全因素及应对措施：如人员变动、需求变化、技术难题5. 对于把控不准的工程进展不同层面的评审1.3.1.2 评审管理方案阶段的评审主要指工程总体方案的评审。1.3.1.2.1 评审输入项?工程总体方案?以及当前工程原始需求等相关资料1.3.1.2.2 评审准那么工程总体方案的评审主要从完整性、正确性、合理性、可管理性进展评审。评审项评审要求备注完整性1. 是否包括从需求至发布各个阶段的任务方案2. 是否对各任务的交付件定义了质量要求正确性1. 各阶段定义是否正确2. 各子任务所属的阶段是否正确合理性1. 各个任务的先后顺序是否合理并串行安排是否合理2. 各任务分配的资源是否合理3. 各任务细化的程度是否合理4. 任务与任务之间的约束是否合理5. 各阶段的时间投入比例是否合理6. 工程的完毕时间，是否与客户承诺的一致7. 工程的方案中是否考虑一些常见的不安全因素8. 对不安全因素的应对是否表达在方案中可管理性1. 对于每个阶段是否有明确的里程碑事件2. 里程碑是否有明确、可衡量的目标3. 里程碑到达时，是否能提供标志阶段完毕的正式输出文档1.3.1.2.3 评审输出评审结果输出包括：1. ?评审结果记录表?1.3.2 需求阶段需求阶段指从需求获取至输出需求规格说明书阶段。需求阶段可划分为：获取需求、分析需求、编写需求规格说明书三个阶段。1. 获取需求：主要从编写工程视图与范围、用户群分类、选择产品/工程需求代表、确定使用实例、分析工作流程、需求重用这几步骤进展2. 分析需求：包括绘制关联图、创立开发原型、分析可行性、划分需求优先级；3. 编写需求标准说明书：根据工程特点裁剪模板、获取功能和技术需求、注明需求来源、开发需求追踪矩阵。1.3.2.1 质量指导方针n 根据?需求模板?、?需求编写指导说明书?制定需求说明文档n 需求文档中应包括明确的需求范围n 需求文档中应包括主要的质量属性n 需求需细化到要求的程度可以根据需求进展开发设计及测试设计n 需求的不确定项不超过总体需求的5%n 需求中应明确定义需求的优先级n 制定需求管理原那么包括需求标识、跟踪方式、变更控制原那么1.3.2.2 评审管理需求阶段评审主要针对需求的清晰性、正确性、完整性、可管理性进展评审。评审的形式按实际的质量方案中要求而定。1.3.2.2.1 评审输入项?技术方案建议书?、?需求分析?、?需求规格说明书?1.3.2.2.2 评审准那么需求评审时，主要针对需求的清晰性、正确性、完整性、可行性、可管理性进展评审，评审细项如以以下图所示：评审项评审要求备注1清晰性1. 系统的目标是否已定义2. 是否对关键术语及略缩语进展了定义3. 是否有对整套系统进展了功能概述2正确性1. 需求与需求之间是否有重复或冲突?2. 本需求说明书与相关需求素材是否一致3. 是否清晰、简洁、无二义地表达了每个需求? 4. 是否每个需求都在工程的范围内5. 是否每个需求都没有内容和语法上的错误? 3完整性1. 编写的所有需求，其详细程度是否一致和适宜? 2. 需求是否能为设计提供足够的根基? 3. 所有对其他需求的内部引用是否正确? 4. 是否已经列出了系统所必要的依赖/假设以及约束5. 是否包含了所有的客户需求或系统需求? 6. 是否已经对每个业务逻辑进展输入、输出以及过程的详细说明7. 是否已详细说明了软件环境共存的软件和硬件环境特定的配置8. 是否遗漏了必要的信息?如果有遗漏的话,把他们标记为待确定的问题(TBD) ? 9. 是否包括了主要的质量属性，例如性能要求、安全性要求、可靠性要求、可恢复性要求、稳定性要求等等10. 是否分析了潜在的需求11. 是否标识并解决了需求中的潜城的问题4可行性1. 所描述的所有功能是否都必要2. 所描述的所有功能是否充分的满足客户/系统目标3. 的限制局限是否已经详细说明4. 是否已经确定每个需求的实现优先级?5. 在现有的资源内, 是否能实现所有的需求?6. 是否每个需求都可以进展验证测试5可管理性1. 是否将需求分别陈述，因此它们是独立的并且是可检查的2. 是否所有需求都可以回溯到相应的需求素材，反之亦然3. 是否已详细说明需求变更的过程一致性1. 是否存在冲突或重复的需求项2. 开发方案/产品和活动和需求是否保持一致3. 是否可以根据软件需求标准中的信息制定出详细的测试集，并且每项需求是否可以测试4. 是否有?需求跟踪矩阵?1.3.2.2.3 评审输出1. ?评审结果清单?2. ?根据评审修订后的需求规格说明书?1.3.3 设计阶段设计阶段包括技术方案形成、概要设计、原型设计、详细设计如果有的话等工作的完成。1.3.3.1 质量指导方针1. 根据概要设计文档模板要求及需求剪裁适合当前工程的模板2. 根据模板编写概要设计说明书3. 对于质量方案中的关键质量属性在设计中需要重点考虑4. 需要针对工程的构造、工程的特征和用户的需求来分析，同样也要考虑到参与工程小组成员的素质5. 对于不同的方案分别进展评估6. 对概要设计文档进展同行评审7. 在设计阶段同时完成原型的设计8. 根据实际需要考虑是否需要进展详细设计9. 涉及到的需求变更需同步知会其它环节的更新。1.3.3.2 评审管理在设计阶段需要对设计实现方案、设计、原型等进展评审；评审的形式按实际的质量方案中要求而定。以下仅提供概要设计说明的评审准那么1.3.3.2.1 评审输入项?概要设计说明书?，?需求规格说明书?1.3.3.2.2 评审准那么概要设计说明书评审准那么评审项评审要求正确性1. 设计说明书的编写是否按照标准模板来编写?2. 设计是否正确是否能够满足需求可行性3. 设计方案在现有条件下是否可行可理解性4. 设计方案是否能被相关人员理解完整性5. 是否包括核心功能的实现方案6. 所有的功能需求与非功能需求是否都表达在了设计中7. 在设计中是否增加了不必要的功能 8. 是否为未来的变更进展了过渡设计9. 各子系统、模块之间的关系是否描述得清楚10. 系统的设计是否考虑了系统的可扩展性11. 设计是否考虑了重用性12. 重用构件是否进展了标识13. 是否说明了重用模块的获取方式和相关的文档14. 系统的设计是否考虑了系统的易移植性15. 设计是否使用标准的技术，防止使用怪异的、不易理解的方式和方法16. 设计的调用宽度、调用深度、耦合度、内聚度和构造化程度是否进展了描述可追溯性17. 设计是否可以跟踪到需求18. 需求是否可以追溯到设计1.3.3.2.3 评审输出?评审结果列表?、评审修订后的?概要设计文档?1.3.4 开发阶段开发阶段主要从代码标准、代码走查、调测等进展控制管理。1.3.4.1 质量指导方针1. 约定开发的编码标准2. 约定代码审计所需的时间及规那么3. 约定开发阶段的调测方式4. 约定开发阶段自测的标准5. 约定提交版本提交的原那么1.3.4.2 代码走查走查项走查要求备注标准性编码是否符合工程或组织的编码标准头文件包含是否完整参数在程度开场时是否被初始化参数在循环开场时是否被初始化在承数或过程调用的时候参数是否被初始化函数调用的格式和参数是否正确变量的声明和拼写是否一致变量声明的范围是否恰当是否所有的指针都被初始化为NULL程序中申请的内存使用后是否释放是否每个=，|等都验证了正确性是否翻开的文件都及时关闭了1.3.5 测试阶段1.3.5.1 质量指导方针1. 尽早的介入测试，所有的测试都可以追溯到需求2. 在测试相应方案启动之前，必须先理解且分析需求3. 根据质量方案来制定相应的测试方案4. 测试方案中需涵盖所有关键质量属性5. 进展测试方案评审及修订6. 建设测试用例对测试需求的覆盖率7. 进展测试用例评审及修订8. 不同测试阶段可有方案的调整当前的测试重点1.3.5.2 评审管理测试评审包括测试方案、测试用例的评审，一般可分为内部评审及外部评审；评审的形式按实际的质量方案中要求而定。以下仅提供测试用例的评审准那么。1.3.5.2.1 评审输入?需求规格说明书?、?概要设计说明书?、?测试方案?、?测试用例?、1.3.5.2.2 评审准那么测试用例评审活动可以确保用例符合优秀用例陈述的特征，包括完整、正确、可行、必要、具有优先级、无二义性和可验证性, 同时亦符合好的用例特征，即完整性、一致性、易修改和可跟踪性；评审过程保证用例满足如下要求：l 完整性：指有明确的目的、输入、输出，提供必要的备注信息；l 正确性：指每个用例的期望结果与实际需求一致；l 可执行性：可执行性指测试人员根据测试用例能够独立执行测试；l 代表性：指能用最简单的数据，最简捷的路径到达测试的目的；l 唯一性：指在各个测试用例没有重复穿插的现象；l 有效性：指每个用例是否有效是否冗余是否能够执行；l 独立性：是用例与用例之间是否互不依赖是否能够独立执行；l 可读性：指测试用例描述清晰，逻辑正确，拆分合理；l 质量指标：指是否能够满足质量指标中的覆盖率要求，是否可以满足BUG密度的质量要求；n 内部评审准那么评审项评审要求备注完整性1. 针对每个测试需求，是否至少有一个正面用例，是否至少有一个以上反面用例去测试2. 针对重要测试需求，是否至少使用了两种以上的设计方法唯一性1. 是否存在重复的用例2. 是否存在可以合并的用例3. 是否存在需要拆分的用例4. 是否存在冗余的用例5. 是否存在无效的用例独立性1. 每一个用例的目的、操作过程、期望结果是否独立2. 每一个用例的目的及期望结果是否保持统一期望结果是否过于发散可读性1. 不同用例之间针对相关联的内容描述是否一样是否存在互斥、矛盾的地方2. 每个测试用例是否清楚的填写了测试特性、步骤、预期结果代表性1. 是否考虑到测试用例的执行效率假设何样的步骤组合才是最高效的2. 测试用例是否具有指导性,是否能灵活指导测试人员通过用例发现更多缺陷,而不是限制他们的思维n 外部评审准那么评审项评审要求备注全面性1. 用例树构造定义是否合理2. 用例是否包括如下方面：功能、界面、性能用例及需求中涉及到的其它方面用例完整性1. 用例是否覆盖了所有显性的需求用例是否覆盖了所有隐性的需求2. 针对每个测试需求，是否从正面、反面分别去验证测试需求3. 测试用例是否覆盖每个被测功能的所有可能的输入输出的组合4. 测试用例是否覆盖正常的输入输出组合的所有可能的取值范围5. 测试用例是否包括测试了被测试对象的初始化过程6. 测试用例是否包含了被测对象中所有异常流的测试7. 是否把最多的测试用例精力放在系统的最主要功能上8. 针对每个测试用例，是否标识了优先级，且标识合理1. 针对每个期望用例的期望结果；对开发的要求是否合理测试开发设计的认识是否一致2. 用例期望结果理中与需求保持一致3. 每一个用例的依赖数据、期望结果是否具体到表及字段的变化质量指标1. 用例覆盖率是否到达相应质量指标? 2. 用例预期缺陷率是否到达相应质量指标?1.3.5.2.3 评审输出?评审结果列表?评审修订通过的测试用例列表?1.3.6 发布及维护阶段1.3.6.1 质量指导方针1. 根据发布阶段要求准备相应的程序及文档2. 及时检查归档的各类资源3. 根据工程特性或公网情况制定现网问题跟踪流及管理方式4. 与用服结合制定软件的客户满意度调查单1.3.7 质量控制中的文档管理质量管理会形成除工程文档之外的管理文档，故文档管理主要为解决工程过程中产生的各类文档的正确性、唯一性、及时性、有效性所做的相应约束。1.3.7.1 文档分类(1)开发文档：这类文档在软件工程开发过程中，表达了软件开发人员前一阶段工作的成果，同时又是后一阶段工作的依据。这类文档包括可行性研究报告、软件工程开发方案、软件需求规格说明、系统规格说明书、软件功能说明书和数据字典等。(2)管理文档：这类文档在软件工程开发过程中，由软件开发人员制定的需提交管理部门的一些工作方案、工作方案和工作报告。通过阅读这些文档，管理人员能够了解软件工程开发活动安排、进度、资源使用等情况。这类文档包括工程开发方案、测试方案、测试方案、开发进度报告和工程总结报告等。(3)用户文档：这类文档是软件开发人员为使用该软件的网点经办人员准备的有关该软件产品使用、操作的资料，主要是操作手册及新功能介绍方面的文档。(4)记录文档：与客户交流往来的记录、软件工程开发过程中各种会议、跟踪记录、审查记录、产品投产记录和问题跟踪解决记录等。(5)反响文档：这类文档主要是软件产品在推广使用以后，客户对产品使用过程中意见及产品缺陷、质量等方面的信息反响。1.3.7.2 文档管理工具文档管理工具现在采用VSS管理方式；存放至文档基线库。文档基线库1.3.7.3 文档管理的 基本要求l 正确性：所有的文档都使用相当的标准模板文档中所述的内容正确无误l 唯一性：每个版本的文档只有一个。l 及时性：文档随每个任务的执行能够及时编制及公布l 有效性：防止无效的文档归档以及过期文档被误用。具体要求：1. 所有的文档都使用相应的标准模2. 文档发布或归档前得到批准3. 必要时对文件进展定期评审与更新4. 确定文件的更改和现行修订状况得到识别5. 确保在使用时可获得有关版本的适用文件6. 确保文件保持清晰、易于识别7. 确保外部文件得到识别并控制其分发8. 防止过期文件被误用，假设因任何原因而保存时，需对其进展适当的标识1.3.7.4 文档管理流程根据现有的状态，文档的管理流程仅涉及归档及发布，如以以下图所示：说明：n 由作者或相应负责人提出归档申请，必须是评审通过且修改后的文档方可提出归档申请n 是否及时归档的检查在各个过程中的检查清单中进展检查n 文档作废：文档归档发布后，需同时作废此文档之前的相应版本。n 每次进展归档后，由归档人员统一进展文档更新发布n 归档之后的文档如有再更新的需求，那么从基线库取出来进展更新后，重新归档。1.4 质量度量：制定工程评估项质量度量主要针对工程进展评估，从工程的方案、过程、质量、本钱、客户满意度不同维度进展评估。具体细节如下。1.4.1 方案评估方案评估主要根据方案历史变更记录来评估方案的正确、合理性、可实施情况，并为以后的方案制定提供参考数据。主要针对里程碑进展评估，对于非里程碑的方案变化不进展评估。1.4.1.1 评估基准1工程启动时的?工程总体方案?、每次变更后的工程方案、工程完毕时的?工程总体方案?2工程变动记录文件1.4.1.2 评估项评估项第x次变更变更原因与上次偏离率%与初始偏离率%方案变更里程碑1里程碑2里程碑31.4.1.3 总结1方案变更的主要原因是什么比方n 工程方案不够详细，工作安排不够细致，时间浪费n 对工程的技术、工作量等认识不清，导致方案时间失误n 对工程人员的工作效率、特长认识不清，导致方案时间失误n 工程任务跟踪不及时，错过最正确调整时机1.4.2 过程评估过程评估是根据工程的每个阶段的质量指导方针以及检查结果来进展的评估，用于检查各工程的过程控制是否到达应有的要求。过程评估最终使用计分的方式来得出过程得分。1.4.2.1 输入条件每个过程的每次的?过程检查清单?1.4.2.2 评估记录评估记录根据对不同阶段的关注不同，定出相应的百分比，以及每个阶段中不同评估项的重点不同，给予不同的分值，最终统计出对过程的总体评分。1.4.2.3 总结对过程得出的最终分进展分析：1. 哪些过程存在严重的质量问题2. 哪些过程缺乏哪些质量控制环节3. 哪些质量控制环节没有起到相应的作用1.4.3 工程质量评估质量评估主要根据测试结果的质量评估以及现网问题跟踪情况进展的评估。1.4.3.1 输入条件1?版本质量评估报告?2现网问题跟踪表1.4.3.2 评估项n 测试阶段评估主要依据测试各类数据根据质量评估标准进展质量评估。n 维护阶段评估主要根据现网问题清单对缺陷率、平均缺陷时间来进展质量评估u 缺陷率：指现网问题数/总问题率u 平均缺陷时间MTF：指平均多久时间反响一个问题。u 平均缺陷恢复时间：指出现一个缺陷后，恢复所需要的时间。1.4.3.3 总结对质量情况得出来的评估结果进展分析。1 测试结果反响情况主要是哪些环节中的问题2 现网问题反响情况主要是哪些环节中的问题3 测试结果反响情况与现网问题反映结果是否一致通过以上总结分析出哪个阶段所存在的问题最多，测试方法/策略是否存在问题；改善明确存在问题的环节。1.4.4 本钱评估本钱评估主要用于评估在各阶段的本钱投入比照是否合理，质量控制本钱投入是否合理，是否存在本钱的浪费等情况。1.4.4.1 输入条件1 工程初始时的?工程总体方案?2 工程完毕时的?工程总体方案?、?工程开发方案?、?测试方案?1.4.4.2 评估项1. 方案本钱指花费在方案环节中所费的本钱，根据最终的工程总体方案统计需求阶段的本钱2. 需求本钱指花费在需求环节所费的本钱；根据最终的工程总体方案统计需求阶段的的本钱3. 设计本钱指花费在设计环节所费的本钱；包括概要设计、原型设计、详细设计等内容的工作本钱。4. 开发本钱指纯开发阶段所费的本钱。5. 质量本钱统计所有因质量活动而引发的本钱，分好本钱、坏本钱，好的本钱包括各预防性的质量控制，如评审、质量检查、测试；坏的本钱指各种返修本钱。n 好质量本钱1) 评审所有活动的本钱2) 测试所有活动的本钱3) 培训等支出的费用n 坏质量本钱1) 各种评审后的返修的本钱2) 测试之后的所有回归修改本钱6. 其它本钱非以上本钱之外的其它本钱，包括其它的一些管理活动、沟通、协调等本钱。1.4.4.3 总结通过以上数据结合其它评估结果分析在各阶段投入的本钱是否合理，哪些本钱是可以通过合理的调整来防止的，哪些本钱投入应该增加。1.4.5 客户满意度评估客户满意度评估主要是由用服协助通过客户满意度调查结果、意见反响单得到的数据而进展的评估。1.4.5.1 输入条件?客户满意度调查结果?、?意见反响表?1.4.5.2 评估项评估项评估结果简析客户满意度质量目标1满意度质量目标2满意度质量目标3满意度非质量目标满意度客户支持要求支持的次数支持的时间1.4.5.3 总结n 客户对非质量目标的满意度高于质量目标：质量保证与控制手段对质量目标未起到作用n 客户对质量目标不关注，更关注非质量目标：质量目标定义不合理n 客户要求支持的次数过多：客户总要求我方支持，是否可理解性过差n 客户要求支持的时间过长：每次支持的时间过长，是否可维护性过差1.5 质量改进质量改进整个质量管理中最后的一个环节，也是一个新的质量管理实施的根基。质量改进环节主要根据工程评估结果，去分析现存在的质量问题及针对问题找出相应的质量改进措施。1.5.1 现存在的质量问题在每个工程告一阶段后，分析整理现在各工程中普遍存在的质量问题，区分主观问题及客观问题；并对存在的质量问题进展原因分析。1.5.2 质量改进措施针对提练出来的质量问题，提出改进措施，并在新工程的质量管理环节中实施，跟进实施的效果。