XX项目质量控制管理方案

《XX项目质量控制管理方案》由会员分享，可在线阅读，更多相关《XX项目质量控制管理方案（20页珍藏版）》请在装配图网上搜索。

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. 主要的质量要性如下：n 功能性质量因素：正确性，健壮性，牢靠性n 非功能性质量因素：性能，易用性，清晰性，平安性，可扩展性，兼容性，可移植性n 其它质量因素：非以上要求之外的要求。2. 依据产品的特性及市场目标，将关键的质量要素确认，同时区分本项目的类型n 倾质量型项目：指本项目对质量限制更关注n 倾成本型项目：指本项目对成本限制更关注n 倾工期型项目：指本项目对工期要求更关注依据以上分析，再制定相应的质量目标

4、。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 人员与职责 参与质量管理活动的人员，一般

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

6、源。1.2.1.4.2 评审1. 确认评审内容及支配；须要包括评审的内容、评审的方式以及评审的人员等等。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、配无论质量目标定为如何，维护性项目的过程检查，仅须要如下环节：l 需求探讨会：是否进行了需求探讨会，需求探讨会的与会人员及结果l 联调：是否进行了联调，对原版本的影响l 测试执行：对测试过程进行检查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. 项目的支配中是否考虑一些常见的

11、风险？8. 对风险的应对是否体现在支配中？可管理性1. 对于每个阶段是否有明确的里程碑事务？2. 里程碑是否有明确、可衡量的目标？3. 里程碑达到时，是否能供应标记阶段结束的正式输出文档？1.3.1.2.3 评审输出评审结果输出包括：1. 评审结果记录表1.3.2 需求阶段需求阶段指从需求获得至输出需求规格说明书阶段。需求阶段可划分为：获得需求、分析需求、编写需求规格说明书三个阶段。1. 获得需求：主要从编写项目视图与范围、用户群分类、选择产品/项目需求代表、确定运用实例、分析工作流程、需求重用这几步骤进行2. 分析需求：包括绘制关联图、创建开发原型、分析可行性、划分需求优先级；3. 编写需求

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

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

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

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

16、求规格说明书1.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.

19、 约定开发的编码规范2. 约定代码审计所需的时间及规则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、征，包括完整、正确、可行、必要、具有优先级、无二义性和可验证性, 同时亦符合好的用例特征，即完整性、一样性、易修改和可跟踪性；评审过程保证用例满足如下要求：l 完整性：指有明确的目的、输入、输出，供应必要的备注信息；l 正确性：指每个用例的期望结果与实际需求一样；l 可执行性：可执行性指测试人员依据测试用例能够独立执行测试；l 代表性：指能用最简洁的数据，最简捷的路径达到测试的目的；l 唯一性：指在各个测试用例没有重复交叉的现象；l 有效性：指每个用例是否有效？是否冗余？是否能够执行；l 独立性：是用例与用例之间是否互不依靠？是否能够独立执行；l 可读性：指测试用例描述清晰，逻辑正确，拆分合理

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

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

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

25、3.6 发布及维护阶段1.3.6.1 质量指导方针1. 依据发布阶段要求打算相应的程序及文档2. 刚好检查归档的各类资源3. 依据项目特性或公网状况制定现网问题跟踪流及管理方式4. 与用服结合制定软件的客户满足度调查单1.3.7 质量限制中的文档管理质量管理睬形成除项目文档之外的管理文档，故文档管理主要为解决项目过程中产生的各类文档的正确性、唯一性、刚好性、有效性所做的相应约束。1.3.7.1 文档分类(1)开发文档：这类文档在软件项目开发过程中，体现了软件开发人员前一阶段工作的成果，同时又是后一阶段工作的依据。这类文档包括可行性探讨报告、软件项目开发支配、软件需求规格说明、系统规格说明书、软

26、件功能说明书和数据字典等。(2)管理文档：这类文档在软件项目开发过程中，由软件开发人员制定的需提交管理部门的一些工作支配、工作方案和工作报告。通过阅读这些文档，管理人员能够了解软件项目开发活动支配、进度、资源运用等状况。这类文档包括项目开发支配、测试支配、测试方案、开发进度报告和项目总结报告等。(3)用户文档：这类文档是软件开发人员为运用该软件的网点经办人员打算的有关该软件产品运用、操作的资料，主要是操作手册及新功能介绍方面的文档。(4)记录文档：与客户沟通往来的记录、软件项目开发过程中各种会议、跟踪记录、审查记录、产品投产记录和问题跟踪解决记录等。(5)反馈文档：这类文档主要是软件产品在推广

27、运用以后，客户对产品运用过程中看法及产品缺陷、质量等方面的信息反馈。1.3.7.2 文档管理工具文档管理工具现在采纳VSS管理方式；存放至文档基线库。文档基线库1.3.7.3 文档管理的基本要求l 正确性：全部的文档都运用相当的标准模板文档中所述的内容正确无误l 唯一性：每个版本的文档只有一个。l 刚好性：文档随每个任务的执行能够刚好编制及公布l 有效性：防止无效的文档归档以及过期文档被误用。具体要求：1. 全部的文档都运用相应的标准模2. 文档发布或归档前得到批准3. 必要时对文件进行定期评审与更新4. 确定文件的更改和现行修订状况得到识别5. 确保在运用时可获得有关版本的适用文件6. 确保

28、文件保持清晰、易于识别7. 确保外部文件得到识别并限制其分发8. 防止过期文件被误用，若因任何缘由而保留时，需对其进行适当的标识1.3.7.4 文档管理流程依据现有的状态，文档的管理流程仅涉及归档及发布，如下图所示：说明：n 由作者或相应负责人提出归档申请，必需是评审通过且修改后的文档方可提出归档申请n 是否刚好归档的检查在各个过程中的检查清单中进行检查n 文档作废：文档归档发布后，需同时作废此文档之前的相应版本。n 每次进行归档后，由归档人员统一进行文档更新发布n 归档之后的文档如有再更新的需求，则从基线库取出来进行更新后，重新归档。1.4 质量度量：制定项目评估项质量度量主要针对项目进行评

29、估，从项目的支配、过程、质量、成本、客户满足度不同维度进行评估。具体细微环节如下。1.4.1 支配评估支配评估主要依据支配历史变更记录来评估支配的正确、合理性、可实施状况，并为以后的支配制定供应参考数据。主要针对里程碑进行评估，对于非里程碑的支配改变不进行评估。1.4.1.1 评估基准1项目启动时的项目总体支配、每次变更后的项目支配、项目结束时的项目总体支配2项目变动记录文件1.4.1.2 评估项评估项第x次变更变更缘由与上次偏离率%与初始偏离率%支配变更里程碑1里程碑2里程碑31.4.1.3 总结1支配变更的主要缘由是什么？比如n 项目支配不够具体，工作支配不够细致，时间奢侈n 对项目的技术

30、、工作量等相识不清，导致支配时间失误n 对项目人员的工作效率、特长相识不清，导致支配时间失误n 项目任务跟踪不刚好，错过最佳调整时机1.4.2 过程评估过程评估是依据项目的每个阶段的质量指导方针以及检查结果来进行的评估，用于检查各项目的过程限制是否达到应有的要求。过程评估最终运用计分的方式来得出过程得分。1.4.2.1 输入条件每个过程的每次的过程检查清单1.4.2.2 评估记录评估记录依据对不同阶段的关注不同，定出相应的百分比，以及每个阶段中不同评估项的重点不同，赐予不同的分值，最终统计出对过程的总体评分。1.4.2.3 总结对过程得出的最终分进行分析：1. 哪些过程存在严峻的质量问题？2.

31、 哪些过程缺乏哪些质量限制环节？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 测试结果反

32、馈状况主要是哪些环节中的问题2 现网问题反馈状况主要是哪些环节中的问题3 测试结果反馈状况与现网问题反映结果是否一样通过以上总结分析出哪个阶段所存在的问题最多，测试方法/策略是否存在问题；改善明确存在问题的环节。1.4.4 成本评估成本评估主要用于评估在各阶段的成本投入比较是否合理，质量限制成本投入是否合理，是否存在成本的奢侈等状况。1.4.4.1 输入条件1 项目初始时的项目总体支配2 项目结束时的项目总体支配、项目开发支配、测试支配1.4.4.2 评估项1. 支配成本指花费在支配环节中所费的成本，依据最终的项目总体支配统计需求阶段的成本2. 需求成本指花费在需求环节所费的成本；依据最终的项

33、目总体支配统计需求阶段的的成本3. 设计成本指花费在设计环节所费的成本；包括概要设计、原型设计、具体设计等内容的工作成本。4. 开发成本指纯开发阶段所费的成本。5. 质量成本统计全部因质量活动而引发的成本，分好成本、坏成本，好的成本包括各预防性的质量限制，如评审、质量检查、测试；坏的成本指各种返修成本。n 好质量成本1) 评审全部活动的成本2) 测试全部活动的成本3) 培训等支出的费用n 坏质量成本1) 各种评审后的返修的成本2) 测试之后的全部回来修改成本6. 其它成本非以上成本之外的其它成本，包括其它的一些管理活动、沟通、协调等成本。1.4.4.3 总结通过以上数据结合其它评估结果分析在各

34、阶段投入的成本是否合理，哪些成本是可以通过合理的调整来避开的，哪些成本投入应当增加。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 质量改进措施针对提练出来的质量问题，提出改进措施，并在新项目的质量管理环节中实施，跟进实施的效果。