优质项目质量控制管理专业方案.docx

项目质量管控方案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 质量改善方法针对提练出来质量问题，提出改善方法，并在新项目标质量管理步骤中实施，跟进实施效果。