项目质量管控方案.docx

《项目质量管控方案.docx》由会员分享，可在线阅读，更多相关《项目质量管控方案.docx（28页珍藏版）》请在课桌文档上搜索。

1、项目质量管控方案1项目质量管控方案1.l序言1.1.1 目的本计划的目的在于对所开发的软件规定多种必要的质量保证措施，以保证所交付的软件可以满足项目预定需求，可以满足本项目总体组制定的且经领导小组评审同意的该软件系统需求规格阐明书中规定的各项详细需求。软件开发项目组在开发软件系统所属日勺各个子系统（其中包括为本项目研发或选用的多种支持软件、组件）时，都应当执行本计划中的有关规定，但可根据各自的状况对本计划作合适的剪裁，以满足特定的质量保证规定，剪裁后的计划必须经项目组有关负责人同意。1.1.2 术语和定义1、质量管理：在质量方面指挥和控制组织的协调活动2、质量筹划：质量管理的一部分，致力于制定

2、质量目日勺并规定必要日勺运行过程3、和有关资源以实现质量目的4、质量控制：质量管理的一部分，致力于满足质量规定5、质量保证：质量管理的一部分，致力于提供质量规定会得到满足的信任6、质量度量：质量管理日勺一部分，致力于对已存在的质量数据进行分析，得出目前质量管理成果的评估数据。7、质量改善：质量管理的一部分，致力于增强满足质量规定的能力1.2质量计划：制定新项目及维护性项目质量计划在本环节中，根据项目的规模及性质进行质量筹划，制定本项目的质量计划；为后续的质量控制、质量评估及质量改善做出行动大纲。针对企业重要有新项目及维护性项目两类版本，且两者之间的质量投入有所差异的特性，故质量计划可以辨别如下

3、：1. 2.1常规项目质量计划规定常规项目的质量计划制定按质量规定分析/质量目的/人员.职责及质量保障、过程检查计划构成，各项的详细规定如下所述。2. 2.1.1质量要素分析1 .重要的质量要性如下： 功能性质量原因：对的性，强健性，可靠性 非功能性质量原因：性能，易用性，清晰性，安全性，可扩展性，兼容性，可移植性 其他质量原因：非以上规定之外的规定。2 .根据产品的特性及市场目的，将关键的质量要素确认，同步辨别本项目的类型 倾质量型项目：指本项目对质量控制更关注 倾成本型项目：指本项目对成本控制更关注 倾工期型项目：指本项目对工期规定更关注根据以上分析，再制定对应的质量目的。签订质量目的时，

4、一般遵照SMART原则S：specific详细的M：measurable可测量的A：achievable可获得的R：realistic切实时T：timely及时B根据以上原则，我们可以制定如下质量目的：1 .例如本项目的质量要素为功能对的性、功能强健性、性能那质量目的可定义例下： 需求中所定义的功能都得以实现 不稳定问题（等级非轻微）都被处理 关键模块（模块名称）的性能不能低于VLO版本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.根据目前的质量目的，确定测试的初步计划，包括测试的范围及测试措施、手段以及投入的人力及时间资源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质量保证与控制质量保证与控制是质量管理中最重要的一种环节，质量目日勺与否可以有效的实现均有赖于此环节的实行控制。本环节根据质量保障计划、过程检查计划对版本开发的各过程定出质量指导方针、评审环节规则以及检查清单。其中质量指导方针：用于简要指导怎样高质量的完毕本阶段的工作评审管理：重要制定简朴日勺评审输入、输出以及该阶段评审日勺基本准则任务检查单：用于检查该阶段的任务与否进行以及进行的效果怎样常存在的问题：更多日勺是让各组员理解某些经验所谈会存在哪些问题，可提前防止或纠1.3.1计划阶段计划阶段

9、指从项目启动至项目总体计划制定完毕的阶段。1. 3.L1质量指导方针在项目的计划阶段，期望产出高质量的项目总体计划，提议遵守如下原则：1 .根据项目总体计划模板、项目总体计划编制阐明书的指导原则进行计划编排2 .计划制定期需结合实际并与有关人员进行必要的沟通3 .理解项目背景、项目目的以及可调动的资源等4 .计划制定期需考虑对应风险及应对措施：如人员变动、需求变化、技术难题5 .对于把控不准的项目进行不同样层面的评审1.3.1.2评审管理计划阶段的评审重要指项目总体计划的评审。1.3.1.2.1评审输入项项目总体计划以及目前项目原始需求等有关资料1.3.1.2.2评审准则项目总体计划的评审重要

10、从完整性、对的性、合理性、可管理性进行评审。评审项评审规电备注完整性1 .与否包括从需求至公布各个阶段的任务计划？2 .与否对各任务的交付件定义了质量规定？对日勺性1.各阶段定义与否对的？评审项评审规定备注2.各子任务所属的阶段与否对的？合理性1 .各个任务的先后次序与否合理？并串行安排与否合理？2 .各任务分派的资源与否合理？3 .各任务细化的程度与否合理？4 .任务与任务之间的约束与否合理？5 .各阶段的时间投入比例与否合理？6 .项目的结束时间，与否与客户承诺的一致7 .项目的计划中与否考虑某些常见的风险？8 .对风险的应对与否体目前计划中？可管理性1 .对于每个阶段与否有明确日勺里程碑

11、事件？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.2评审准则需求评审时，重要针对需求的清晰性、对的性、完整性、可

13、行性、可管理性进行评审,评审细项如下图所示：评审项评审规定备注1.清晰性1.系统的目日勺与否已定义？2.与否对关键术语及略缩语进行了定义？评审项评审规定备注3.与否有对整套系统进行了功能概述？2.对时性1.需求与需求之间与否有反复或冲突？2.本需求阐明书与有关需求素材与否一致？3.与否清晰、简洁、无二义地体现了每个需求？4.与否每个需求都在项目日勺范围内5.与否每个需求都没有内容和语法上日勺错误？3.完整性1.编写的所有需求，其详细程度与否一致和合适？2.需求与否能为设计提供足够的基础？3.所有对其他需求的内部引用与否对时？4.与否已经列出了系统所必要日勺依赖/假设以及约束5.与否包括了所有已

14、知日勺客户需求或系统需求？6.与否已经对每个业务逻辑进行输入、输出以及过程的详细阐明7.与否已详细阐明了软件环境（共存的软件）和硬件环境（特定的配置）8.与否遗漏了必要的信息？假如有遗漏日勺话，把他们标识为待确定的问题（TBD）?9.与否包括了重要的质量属性，例如性能规定、安全性规定、可靠性规定、可恢复性规定、稳定性规定等等10.与否分析了潜在的需求11.与否标识并处理了需求中的潜城的问题4.可行1.所描述的所有功能与否都必要？性2.所描述的所有功能与否充足的满足客户/系统目的？3.已知日勺限制（局限）与否已经详细阐明？4.与否已经确定每个需求日勺实现优先级？5.在既有日勺资源内，与否能实现所

15、有日勺需求？6.与否每个需求都可以进行验证（测试）？5.可管理性1.与否将需求分别陈说，因此它们是独立的并且是可检查时？2.与否所有需求都可以回溯到对应的需求素材，反之亦然？3.与否已详细阐明需求变更的过程？一致性1.与否存在冲突或反复的需求项2.开发计划/产品和活动和需求与否保持一致3.与否可以根据软件需求规范中的信息制定出详细的测试集，并且每项需求与否可以测试4.与否有需求跟踪矩阵1. 3.2.2.3评审输出1 .评审成果清单2 .根据评审修订后的需求规格阐明书1. 3.3设计阶段设计阶段包括技术方案形成、概要设计、原型设计、详细设计（假如有日勺话）等工作的完毕。2. 3.3.1质量指导方

16、针1 .根据概要设计文档模板规定及需求剪裁适合目前项目的模板2 .根据模板编写概要设计阐明书3 .对于质量计划中的关键质量属性在设计中需要重点考虑4 .需要针对项目的构造、项目的特性和顾客的需求来分析，同样也要考虑到参与项目小组组员的素质5 .对于不同样的方案分别进行评估6 .对概要设计文档进行同行评审7 .在设计阶段同步完毕原型的设计8 .根据实际需要考虑与否需要进行详细设计9 .波及到时需求变更需同步知会其他环节的更新。在设计阶段需要对设计实现方案、设计、原型等进行评审；评审的形式按实际日勺质量计划中规定而定。如下仅提供概要设计阐明的评审准则1.3.3.2.1评审输入项概要设计阐明书，需求

17、规格阐明书1.3.3.2.2评审准则概要设计阐明书评审准则评审项评审规定对的性1.设计阐明书的编写与否按照原则模板来编写？2.设计与否对的？与否可以满足需求？可行性3.设计方案在既有条件下与否可行？可理解性4.设计方案与否能被有关人员理解？完整性5.与否包括关键功能的实现方案？6.所有的功能需求与非功能需求与否都体目前了设计中？7.在设计中与否增长了不必要的功能？8.与否为未来的变更进行了过渡设计？9.各子系统、模块之间的关系与否描述得清晰10.系统的设计与否考虑了系统的可扩展性11.设计与否考虑了重用性12.重用构件与否进行了标识13.与否阐明了重用模块的获取方式和有关的文档14.系统的设计

18、与否考虑了系统的易移植性15.设计与否使用原则的技术，防止使用怪异日勺、不易理解日勺方式和措施16.设计的调用宽度、调用深度、耦合度、内聚度和构造化程度与否进行了描述可追溯性17.设计与否可以跟踪到需求18.需求与否可以追溯到设计评审成果列表、评审修订后的概要设计文档1.3.4开发阶段开发阶段重要从代码规范、代码走查、调测等进行控制管理。1. 3.4.1质量指导方针1 .约定开发的编码规范2 .约定代码审计所需的时间及规则3 .约定开发阶段的调测方式4 .约定开发阶段自测的原则.约定提交版本提交的原则1.3.4.2代码走查走查项走查规定备注规范性编码与否符合项目或组织日勺编码原则头文献包括与否

19、完整参数在程度开始时与否被初始化参数在循环开始时与否被初始化在承数或过程调用的时候参数与否被初始化函数调用日勺格式和参数与否对日勺变量日勺申明和拼写与否一致变量申明的范围与否恰当与否所有日勺指针都被初始化为NULL程序中申请日勺内存使用后与否释放与否每个=,11等都验证了对日勺性与否打开日勺文献都及时关闭了1. 3.5测试阶段2. 3.5.1质量指导方针1 .尽早的介入测试，所有的测试都可以追溯到需求2 .在测试对应方案后动之前，必须先理解且分析需求3 .根据质量计划来制定对应的测试计划4 .测试计划中需涵盖所有关键质量属性5 .进行测试计划评审及修订6 .建立测试用例对测试需求的覆盖率7 .

20、进行测试用例评审及修订8 .不同样测试阶段可有计划的调整目前的测试重点1.3.5.2评审管理测试评审包括测试方案、测试用例的评审，一般可分为内部评审及外部评审；评审的形式按实际的质量计划中规定而定。如下仅提供测试用例的评审准则。1.3.5.2.1评审输入需求规格阐明书、概要设计阐明书、测试计划、测试用例、1.3.5.2.2评审准则测试用例评审活动可以保证用例符合优秀用例陈说的特性，包括完整、对的、可行、必要、具有优先级、无二义性和可验证性，同步亦符合好的用例特性，即完整性、一致性、易修改和可跟踪性；评审过程保证用例满足如下规定： 完整性：指有明确的目的、输入、输出，提供必要的备注信息； 对的性

21、：指每个用例的期望成果与实际需求一致； 可执行性：可执行性指测试人员根据测试用例可以独立执行测试； 代表性：指能用最简朴的数据，最简捷的途径抵达测试的目的； 唯一性：指在各个测试用例没有反复交叉的现象； 有效性：指每个用例与否有效？与否冗余？与否可以执行； 独立性：是用例与用例之间与否互不依赖？与否可以独立执行； 可读性：指测试用例描述清晰，逻辑对的，拆分合理； 质量指标：指与否可以满足质量指标中日勺覆盖率规定，与否可以满足BUG密度日勺质量规定;内部评审准则评审项评审规定备注完整性1 .针对每个测试需求，与否至少有一种正面用例，与否至少有一种以上背面用例去测试？2 .针对重要测试需求，与否至

22、少使用了两种以上的设计措施？唯一性1 .与否存在反复日勺用例？2 .与否存在可以合并的用例？3 .与否存在需要拆分的用例？4 .与否存在冗余日勺用例？5 .与否存在无效日勺用例？独立性1.每一种用例日勺目日勺、操作过程、期望成果与否独立？2,每一种用例日勺目日勺及期望成果与否保持统一？期望成果与否过于发散？可读性1 .不同样用例之间针对有关联的内容描述与否相似？与否存在互斥、矛盾的地方？2 .每个测试用例与否清晰时填写了测试特性、环节、预期成果？代表性1 .与否考虑到测试用例的执行效率？怎么样的环节组合才是最高效的？2 .测试用例与否具有指导性，与否能灵活指导测试人员通过用例发现更多缺陷，而不

23、是限制他们的思维外部评审准则评审项评审规定备注全面性1 .用例树构造定义与否合理？2 .用例与否包括如下方面：功能、界面、性能用例及需求中波及到日勺其他方面用例完整性1 .用例与否覆盖了所有显性日勺需求？用例与否覆盖了所有隐性日勺需求2 .针对每个测试需求，与否从正面、背面分别去验证测试需求？3 .测试用例与否覆盖每个被测功能日勺所有也许日勺输入输出日勺组合？4 .测试用例与否覆盖正常日勺输入输出组合日勺所有也许日勺取值范围？5 .测试用例与否包括测试了被测试对象日勺初始化过程？6 .测试用例与否包括了被测对象中所有异常流日勺测试？7 .与否把最多日勺测试用例精力放在系统日勺最重要功能上？8

24、.针对每个测试用例，与否标识了优先级，且标识合理？1 .针对每个期望用例时期望成果；对开发的规定与否合理？测试开发设计的认识与否一致？2 .用例期望成果理中与需求保持一致？3 .每一种用例日勺依赖数据、期望成果与否详细到表及字段的变化？质量指标1 .用例覆盖率与否抵达对应质量指标？2 .用例预期缺陷率与否抵达对应质量指标？1.3.5.2.3评审输出评审成果列表评审修订通过的测试用例列表1. 3.6公布及维护阶段2. 3.6.1质量指导方针1 .根据公布阶段规定准备对应的程序及文档2 .及时检查归档的各类资源3 .根据项目特性或公网状况制定现网问题跟踪流及管理方式4 .与用服结合制定软件的客户满

25、意度调查单1. 3.7质量控制中的文档管理质量管理会形成除项目文档之外的管理文档，故文档管理重要为处理项目过程中产生日勺各类文档的对的性、唯一性、及时性、有效性所做的对应约束。2. 3.7.1文档分类(D开发文档：此类文档在软件项目开发过程中，体现了软件开发人员前一阶段工作的成果，同步又是后一阶段工作的根据。此类文档包括可行性研究汇报、软件项目开发计划、软件需求规格阐明、系统规格阐明书、软件功能阐明书和数据字典等。(2)管理文档：此类文档在软件项目开发过程中，由软件开发人员制定的需提交管理部门的某些工作计划、工作方案和工作汇报。通过阅读这些文档，管理人员可以理解软件项目开发活动安排、进度、资源

26、使用等状况。此类文档包括项目开发计划、测试计划、测试方案、开发进度汇报和项目总结汇报等。(3)顾客文档：此类文档是软件开发人员为使用该软件的网点经办人员准备日勺有关该软件产品使用、操作的资料，重要是操作手册及新功能简介方面的文档。(4)记录文档：与客户交流往来的记录、软件项目开发过程中多种会议、跟踪记录、审查记录、产品投产记录和问题跟踪处理记录等。(5)反馈文档：此类文档重要是软件产品在推广使用后来，客户对产品使用过程中意见及产品缺陷、质量等方面的信息反馈。1. 3.7.2文档管理工具文档管理工具目前采用VSS管理方式；寄存至文档基线库。文档基线库1.3.7.3文档管理的基本规定 对的性：所有

27、的文档都使用相称的原则模板文档中所述的内容对的无误 唯一性：每个版本的文档只有一种。 及时性：文档随每个任务的执行可以及时编制及公布 有效性：防止无效的文档归档以及过期文档被误用。详细规定：1 .所有的文档都使用对应的原则模2 .文档公布或归档前得到同意3 .必要时对文献进行定期评审与更新4 .确定文献的更改和现行修订状况得到识别5 .保证在使用时可获得有关版本的合用文献6 .保证文献保持清晰、易于识别7 .保证外部文献得到识别并控制其分发.防止过期文献被误用，若因任何原因而保留时，需对其进行合适的标识1.3.7.4文档管理流程根据既有的状态，文档的管理流程仅波及归档及公布，如下图所示:阐明：

28、 由作者或对应负责人提出归档申请，必须是评审通过且修改后的文档方可提出归档申请 与否及时归档的检查在各个过程中的检查清单中进行检查 文档作废：文档归档公布后，需同步作废此文档之前的对应版本。 每次进行归档后，由归档人员统一进行文档更新公布归档之后的文档如有再更新的需求，则从基线库取出来进行更新后，重新归档。1.4质量度量：制定项目评估项质量度量重要针对项目进行评估，从项目的计划、过程、质量、成本、客户满意度不同样维度进行评估。详细细节如下。1.4.1计划评估计划评估重要根据计划历史变更记录来评估计划时对时、合理性、可实行状况，并为后来的计划制定提供参照数据。重要针对里程碑进行评估，对于非里程碑

29、的计划变化不进行评估。1. 4.1.1评估基准1 .项目启动时的项目总体计划、每次变更后的项目计划、项目结束时的项目总体计划2 .项目变动记录文献1.4.1.2评估项评估项第X次变更变更原因与上次偏与初始偏离率离率计划变更里程碑1里程碑2里程碑31. 4.L3总结1 .计划变更的重要原因是什么？例如 项目计划不够详细，工作安排不够细致，时间挥霍 对项目的技术、工作量等认识不清，导致计划时间失误 对项目人员的工作效率、专长认识不清，导致计划时间失误 项目任务跟踪不及时，错过最佳调整时机1.4.2过程评估过程评估是根据项目的每个阶段的质量指导方针以及检查成果来进行的评估，用于检查各项目的过程控制与

30、否抵达应有的规定。过程评估最终使用计分的方式来得出过程得分。1. 4.2.1输入条件每个过程的每次的过程检查清单2. 4.2.2评估记录评估记录根据对不同样阶段的关注不同样，定出对应的比例，以及每个阶段中不同样评估项的重点不同样，予以不同样的分值，最终记录出对过程的总体评分。2.4. 2.3总结对过程得出时最终分进行分析：1 .哪些过程存在严重的质量问题？2 .哪些过程缺乏哪些质量控制环节？3 .哪些质量控制环节没有起到对应的作用？1.4.3项目质量评估质量评估重要根据测试成果的质量评估以及现网问题跟踪状况进行的评估。1.4. 3.1输入条件1 .版本质量评估汇报2 .现网问题跟踪表1.4.

31、3.2评估项测试阶段评估重要根据测试各类数据根据质量评估原则进行质量评估。维护阶段评估重要根据现网问题清单对缺陷率、平均缺陷时间来进行质量评估 缺陷率：指现网问题数/总问题率 平均缺陷时间（MTF）：指平均多久时间反馈一种问题。平均缺陷恢复时间：指出现一种缺陷后，恢复所需要的时间。1.4.3.3总结对质量状况得出来的评估成果进行分析。1 .测试成果反馈状况重要是哪些环节中的问题2 .现网问题反馈状况重要是哪些环节中的问题3 .测试成果反馈状况与现网问题反应成果与否一致通过以上总结分析出哪个阶段所存在的问题最多，测试措施/方略与否存在问题；改善明确存在问题的环节。1. 4.4成本评估成本评估重要

32、用于评估在各阶段的成本投入比较与否合理，质量控制成本投入与否合理，与否存在成本的挥霍等状况。1.4.4.1输入条件1 .项目初始时的项目总体计划2 .项目结束时的项目总体计划、项目开发计划、测试计划1.4. 4.2评估项1 .计划成本指花费在计划环节中所费的成本，根据最终的项目总体计划记录需求阶段的成本2 .需求成本指花费在需求环节所费的成本；根据最终的项目总体计划记录需求阶段的的成本3 .设计成本指花费在设计环节所费的成本；包括概要设计、原型设计、详细设计等内容的工作成本。4 .开发成本指纯开发阶段所费的成本。5 .质量成本记录所有因质量活动而引起的成本，分好成本、坏成本，好的成本包括各防止

33、性的质量控制，如评审、质量检查、测试；坏的成本指多种返修成本。好质量成本1）评审所有活动的成本2）测试所有活动的成本3）培训等支出的费用坏质量成本1）多种评审后的返修的成本2）测试之后的所有回归修改成本6 .其他成本非以上成本之外的其他成本，包括其他的某些管理活动、沟通、协调等成本。1.4.4.3总结通过以上数据结合其他评估成果分析在各阶段投入的成本与否合理，哪些成本是可以通过合理的调整来防止的，哪些成本投入应当增长。1.4.5客户满意度评估客户满意度评估重要是由用服协助通过客户满意度调查成果、意见反馈单得到的数据而进行的评估。1.4.5.1输入条件客户满意度调查成果、意见反馈表1.4.5.2

34、评估项评估项评估成果简析客户满意度质量目日勺1满意度质量目的2满意度质量目的3满意度非质量目的满意度客户支持规定支持的次数支持日勺时间1. 4.5,3总结 客户对非质量目的的满意度高于质量目的：质量保证与控制手段对质量目日勺未起到作用？ 客户对质量目的不关注，更关注非质量目的：质量目的定义不合理？ 客户规定支持的次数过多：客户总规定我方支持，与否可理解性过差？客户规定支持的时间过长：每次支持的时间过长，与否可维护性过差1.5质量改善质量改善整个质量管理中最终的一种环节，也是一种新的质量管理实行的基础。质量改善环节重要根据项目评估成果，去分析现存在的质量问题及针对问题找出对应的质量改善措施。1.5.1现存在的质量问题在每个项目告一阶段后，分析整顿目前各项目中普遍存在的质量问题，辨别主观问题及客观问题；并对存在日勺质量问题进行原因分析。1.5.2质量改善措施针对提练出来的质量问题，提出改善措施，并在新项目的质量管理环节中实行，跟进实行的效果。