软件质量管理手册样本

质量管理手册

目录1 前言 51.1 读者对象 51.2 目和范畴 51.3 术语和定义 52 总体阐明 53 质量筹划：制定新项目及维护性项目质量筹划 53.1 常规项目质量筹划规定 63.1.1 质量要素分析 63.1.2 质量目的 63.1.3 人员与职责 73.1.4 质量保障筹划 73.1.5 过程检查筹划 73.2 维护性项目质量筹划规定 83.2.1 质量目的 83.2.2 质量保障筹划 83.2.3 过程检查筹划 84 质量保证与控制 84.1 筹划阶段 94.1.1 质量指引方针 94.1.2 评审管理 94.1.3 筹划阶段检查单 104.1.4 常存在问题 114.2 需求阶段 114.2.1 质量指引方针 114.2.2 评审管理 124.2.3 需求阶段检查单 134.2.4 常存在问题 144.3 设计阶段 144.3.1 质量指引方针 144.3.2 评审管理 144.3.3 设计阶段检查单 154.3.4 常存在问题 164.4 开发阶段 164.4.1 质量指引方针 164.4.2 代码走查 174.4.3 开发阶段检查单 174.4.4 常存在问题 184.5 测试阶段 184.5.1 质量指引方针 184.5.2 评审管理 184.5.3 检查清单 214.5.4 常存在问题 224.6 发布及维护阶段 234.6.1 质量指引方针 234.6.2 发布及维护阶段检查清单 234.6.3 常存在问题 244.7 质量控制中文档管理 244.7.1 文档分类 244.7.2 文档管理工具 244.7.3 文档管理基本规定 244.7.4 文档管理流程 255 质量度量：制定项目评估项 255.1 筹划评估 265.1.1 评估基准 265.1.2 评估项 265.1.3 总结 265.2 过程评估 265.2.1 输入条件 275.2.2 评估登记表 275.2.3 总结 285.3 项目质量评估 285.3.1 输入条件 285.3.2 评估项 285.3.3 总结 295.4 成本评估 295.4.1 输入条件 295.4.2 评估项 295.4.3 总结 305.5 客户满意度评估 315.5.1 输入条件 315.5.2 评估项 315.5.3 总结 316 质量改进 316.1 现存在质量问题 326.2 质量改进办法 326.2.1 问题XXXX 326.2.2 产生因素分析 326.2.3 防止办法 327 附录一：评审过程检查表 338 附录二：参照及依从规范文档清单 349 附录三：项目管理跟踪管理 34

前言读者对象本文档读者对象涉及质量管理人员、项目构成员及研发管理人员。目和范畴本文档目为了指引研发部进行质量管理环节及办法/原则。合用范畴为研发部质量管理作参照，以杜绝或减少研发过程中浮现质量问题，并对质量管理成果作出相应改进。术语和定义质量管理：在质量方面指挥和控制组织协调活动质量策划：质量管理一某些，致力于制定质量目的并规定必要运营过程和有关资源以实现质量目的质量控制：质量管理一某些，致力于满足质量规定质量保证：质量管理一某些，致力于提供质量规定会得到满足信任质量度量：质量管理一某些，致力于对已存在质量数据进行分析，得出当前质量管理成果评估数据。质量改进：质量管理一某些，致力于增强满足质量规定能力总体阐明由于既有研发过程成熟限度较低，质量管理不能一开始即从非常高原则入手，故依照研发部现状，质量管理初步从4个方面着手：筹划（拟定过程）、保证及检查（控制过程）、评估（测量过程）、改进（改进过程）。以防止式管理为方向，控制、检查为手段，持续改进并提高项目质量为最后目。鉴于质量管理在本阶段为初次正式引入，故对控制及检查、评估环节中规定并不完善，以减少实行过程中过多阻碍。质量筹划：制定新项目及维护性项目质量筹划在本环节中，依照项目规模及性质进行质量策划，制定本项目质量筹划；为后续质量控制、质量评估及质量改进做出行动大纲。针对公司重要有新项目及维护性项目两类版本，且两者之间质量投入有所差别特性，故质量筹划可以区别如下：常规项目质量筹划规定常规项目质量筹划制定按质量规定分析/质量目的/人员.职责及质量保障、过程检查筹划构成，各项详细规定如下所述。质量要素分析重要质量要性如下：功能性质量因素：对的性，健壮性，可靠性非功能性质量因素：性能，易用性，清晰性，安全性，可扩展性，兼容性，可移植性其他质量因素：非以上规定之外规定。依照产品特性及市场目的，将核心质量要素确认，同步区别本项目类型倾质量型项目：指本项目对质量控制更关注倾成本型项目：指本项目对成本控制更关注倾工期型项目：指本项目对工期规定更关注依照以上分析，再制定相应质量目的。质量目的订立质量目的时，普通遵循SMART原则S：specific详细M：measurable可测量A：achievable可获得R：realistic切实T：timely及时依照以上原则，咱们可以制定如下质量目的：例如本项目质量要素为功能对的性、功能健壮性、性能那质量目的可定义例下：需求中所定义功能都得以实现不稳定问题（级别非轻微）都被解决核心模块（模块名称）性能不能低于V1.0版本……针对质量目的定出优先级1、3、2目的分解分解为阶段质量目的完毕阶段质量目的手段人员与职责参加质量管理活动人员，普通状况下，项目组所有人都可以参加到质量管理活动中来。但咱们普通可定义如下人员去分别承担相应职责。质量管理人员：制定质量管理筹划，对质量过程进行控制；对过程检查单进行实行；进行质量度量，制定质量改进筹划及实行；参加各类评审活动。测试人员：制定测试筹划，对项目进行测试，进行测试成果度量分析；参加各类评审活动。项目管理人员：协助组织解决质量管理过程中所发现各类问题及风险。质量保障筹划依照当前质量目的，筹划需要进行哪些质量保障工作，普通可涉及专业培训、同级评审、测试。培训确认与否需要培训确认培训内容、人员、时间，以及所耗费资源。评审确认评审内容及筹划；需要涉及评审内容、评审方式以及评审人员等等。对评审成果跟踪、管理方式。测试依照当前质量目的，拟定测试初步筹划，涉及测试范畴及测试办法、手段以及投入人力及时间资源过程检查筹划依照当前质量目的，制定项目过程中需要检核对象、例如：阶段检核对象检查时机次数检查执行人员检查根据筹划阶段筹划阶段产出项目构成立之后至筹划阶段结束3次相应测试接口人依照筹划阶段检查清单进行检查需求阶段需求评审需求评审启动1次相应测试接口人依照需求阶段检查清单进行检查。维护性项目质量筹划规定维护性项目质量筹划制定相对简朴，不需要花较多时间在其上，并且可以套用比较固定模板。维护性项目基本上会有很明确需求点以及详细时间点规定，普通状况下，维护时期会很长，且需求相对较散、小，针对这些特性，维护性项目质量筹划规定仅可以涉及：质量目的、质量保障筹划、过程检查筹划。质量目的依照当前需求简朴定出本版本质量目的。质量保障筹划在维护性项目中，质量保障筹划重要涉及：需求讨论、联调以及测试。需求讨论：参加人员涉及开发及测试人员；需求讨论成果报告联调：对所做修改及周边进行联调；联调测试报告测试：依照质量目的制定相应测试筹划安排，过程检查筹划无论质量目的定为如何，维护性项目过程检查，仅需要如下环节：需求讨论会：与否进行了需求讨论会，需求讨论会与会人员及成果联调：与否进行了联调，对原版本影响测试执行：对测试过程进行检查子过程评估项评估成果得分单项分*比例有(√)没有(×)N/A需求讨论（50%）与否发起需求讨论会？（60分）与会人员涉及与否合理？(40分)联调测试（20%）进行了联调测试（60分）联调与否有效发现问题数是测试20%(40分)测试（30%）测试具备用例或测试点？(50分)测试执行与否能被跟踪(50分)质量保证与控制质量保证与控制是质量管理中最重要一种环节，质量目的与否可以有效实现均有赖于此环节实行控制。本环节依照质量保障筹划、过程检查筹划对版本开发各过程定出质量指引方针、评审环节规则以及检查清单。其中质量指引方针：用于简要指引如何高质量完毕本阶段工作评审管理：重要制定简朴评审输入、输出以及该阶段评审基本准则任务检查单：用于检查该阶段任务与否进行以及进行效果如何常存在问题：更多是让各成员理解某些经验所谈会存在哪些问题，可提前防止或纠正筹划阶段筹划阶段指从项目启动至项目总体筹划制定完毕阶段。质量指引方针在项目筹划阶段，盼望产出高质量项目总体筹划，建议遵守如下原则：依照《项目总体筹划模板》、《项目总体筹划编制阐明书》指引原则进行筹划编排筹划制定期需结合实际并与有关人员进行必要沟通理解项目背景、项目目的以及可调动资源等筹划制定期需考虑相应风险及应对办法：如人员变动、需求变化、技术难题对于把控不准项目进行不同层面评审评审管理筹划阶段评审重要指项目总体筹划评审。评审输入项《项目总体筹划》以及当前项目原始需求等有关资料评审准则项目总体筹划评审重要从完整性、对的性、合理性、可管理性进行评审。评审项评审规定备注完整性与否涉及从需求至发布各个阶段任务筹划？与否对各任务交付件定义了质量规定？对的性各阶段定义与否对的？各子任务所属阶段与否对的？合理性各个任务先后顺序与否合理？并串行安排与否合理？各任务分派资源与否合理？各任务细化限度与否合理？任务与任务之间约束与否合理？各阶段时间投入比例与否合理？项目结束时间，与否与客户承诺一致项目筹划中与否考虑某些常用风险？对风险应对与否体当前筹划中？可管理性对于每个阶段与否有明确里程碑事件？里程碑与否有明确、可衡量目的？里程碑达届时，与否能提供标志阶段结束正式输出文档？评审输出评审成果输出涉及：《评审成果登记表》《修订后项目总体筹划》筹划阶段检查单编号：项目名称项目编号软件项目经理本次检查所费时间报告人日期检查内容已经完毕某些完毕尚未完毕不合用注释项目估算对项目进行了合理分解，并区别复杂度对项目进行了规模和工作量估算，并符合估算过程对项目进行了进度、风险、资源、成本估算对估算成果进行了评审，并符合规定策划过程选取了适当生命周期模型同步考虑了项目管理、集成、测试、SCM、SQA等工作定义了合理里程碑且每个里程碑目的清晰已经剔除了停工、假期等影响工作时间因素策划形成筹划与顾客规定、合同等不相矛盾筹划评审及跟踪筹划发起了评审筹划评审过程符合公司规定、原则规定筹划评审过程有效（评审所发现问题数（用于检查评审与否有效，与否达到预期，以及交付件质量）评审所反馈问题已经妥善解决修订后筹划已经纳入基线库审核签字角色姓名签字日期软件项目经理研发经理常存在问题筹划中并行工作先后顺序安排不合理筹划中没有预留任何应对风险办法筹划中未涉及整个项目所有工作筹划中不拟定因素过多需求阶段需求阶段指从需求获取至输出需求规格阐明书阶段。需求阶段可划分为：获取需求、分析需求、编写需求规格阐明书三个阶段。获取需求：重要从编写项目视图与范畴、顾客群分类、选取产品/项目需求代表、拟定使用实例、分析工作流程、需求重用这几环节进行分析需求：涉及绘制关联图、创立开发原型、分析可行性、划分需求优先级；编写需求规范阐明书：依照项目特点裁剪模板、获取功能和技术需求、注明需求来源、开发需求追踪矩阵。质量指引方针依照《需求模板》、《需求编写指引阐明书》制定需求阐明文档需求文档中应涉及明确需求范畴需求文档中应涉及重要质量属性需求需细化到规定限度（可以依照需求进行开发设计及测试设计）需求不拟定项不超过总体需求5%需求中应明拟定义需求优先级制定需求管理原则（涉及需求标记、跟踪方式、变更控制原则）评审管理需求阶段评审重要针对需求清晰性、对的性、完整性、可管理性进行评审。评审形式按实际质量筹划中规定而定。评审输入项《技术方案建议书》、《需求分析》、《需求规格阐明书》评审准则需求评审时，重要针对需求清晰性、对的性、完整性、可行性、可管理性进行评审，评审细项如下图所示：评审项评审规定备注1．清晰性系统目的与否已定义？与否对核心术语及略缩语进行了定义？与否有对整套系统进行了功能概述？2．对的性需求与需求之间与否有重复或冲突?本需求阐明书与有关需求素材与否一致？与否清晰、简洁、无二义地表达了每个需求?与否每个需求都在项目范畴内与否每个需求都没有内容和语法上错误?3．完整性编写所有需求，其详细限度与否一致和适当?需求与否能为设计提供足够基本?所有对其她需求内部引用与否对的?与否已经列出了系统所必要依赖/假设以及约束与否包括了所有已知客户需求或系统需求?与否已经对每个业务逻辑进行输入、输出以及过程详细阐明与否已详细阐明了软件环境（共存软件）和硬件环境（特定配备）与否漏掉了必要信息?如果有漏掉话,把她们标记为待拟定问题(TBD)?与否涉及了重要质量属性，例如性能规定、安全性规定、可靠性规定、可恢复性规定、稳定性规定等等与否分析了潜在需求与否标记并解决了需求中潜城问题4．可行性所描述所有功能与否都必要？所描述所有功能与否充分满足客户/系统目的？已知限制（局限）与否已经详细阐明？与否已经拟定每个需求实现优先级?在既有资源内，与否能实现所有需求?与否每个需求都可以进行验证（测试）？5．可管理性与否将需求分别陈述，因而它们是独立并且是可检查？与否所有需求都可以回溯到相应需求素材，反之亦然？与否已详细阐明需求变更过程？一致性与否存在冲突或重复需求项开发筹划/产品和活动和需求与否保持一致与否可以依照软件需求规范中信息制定出详细测试集，并且每项需求与否可以测试与否有《需求跟踪矩阵》评审输出《评审成果清单》《依照评审修订后需求规格阐明书》需求阶段检查单项目名称项目编号软件项目经理本次检查耗费时间报告人日期检查内容是否无法确认N/A注释需求确立系统需求明确及其分派已形成文档软件需求明确并按照模版形成文档需求管理中重要质量属性已经确认已与受影响组和个人协商需求商定需求中不可测试某些已经进行标记需求评审及跟踪需求通过评审需求评审过程有效（发现问题达到一定级别）需求评审中发现问题都已妥善解决需求已通过客户或高档管理者承认并签字确认修订后需求规格阐明书与否纳入基线库需求变更控制已经建立需求变更控制流程需求变动状况与否在软件需求阐明书进行登记内部受影响组织已理解和承诺更改对更改所导致风险和影响已进行辨认、评价并文档化进度跟踪进度与否延期？如果延期，延期与否在可控范畴内？审核签字角色姓名签字日期软件项目经理研发总监常存在问题需求未通过度析直接转给其他人员需求不够细化，开发及测试设计无法进行需求中不确认需求点过多需求不完整、不全面设计阶段设计阶段涉及技术方案形成、概要设计、原型设计、详细设计（如果有话）等工作完毕。质量指引方针依照概要设计文档模板规定及需求剪裁适合当前项目模板依照模板编写概要设计阐明书对于质量筹划中核心质量属性在设计中需要重点考虑需要针对项目构造、项目特性和顾客需求来分析，同样也要考虑到参加项目小构成员素质对于不同方案分别进行评估对概要设计文档进行同行评审在设计阶段同步完毕原型设计依照实际需要考虑与否需要进行详细设计涉及到需求变更需同步知会其他环节更新。评审管理在设计阶段需要对设计实现方案、设计、原型等进行评审；评审形式按实际质量筹划中规定而定。如下仅提供概要设计阐明评审准则评审输入项《概要设计阐明书》，《需求规格阐明书》评审准则概要设计阐明书评审准则评审项评审规定对的性设计阐明书编写与否按照原则模板来编写?设计与否对的？与否可以满足需求？可行性设计方案在既有条件下与否可行？可理解性设计方案与否能被有关人员理解？完整性与否涉及核心功能实现方案？所有功能需求与非功能需求与否都体当前了设计中？在设计中与否增长了不必要功能？与否为将来变更进行了过渡设计？各子系统、模块之间关系与否描述得清晰系统设计与否考虑了系统可扩展性设计与否考虑了重用性重用构件与否进行了标记与否阐明了重用模块获取方式和有关文档系统设计与否考虑了系统易移植性设计与否使用原则技术，避免使用怪异、不易理解方式和办法设计调用宽度、调用深度、耦合度、内聚度和构造化限度与否进行了描述可追溯性设计与否可以跟踪到需求需求与否可以追溯到设计评审输出《评审成果列表》、评审修订后《概要设计文档》设计阶段检查单项目名称项目编号软件项目经理本次检查耗费时间报告人日期检查内容已经完毕某些完毕尚未完毕不合用注释设计确认与否具备概要设计阐明书设计阐明书编写按照原则模板来编写设计评审及跟踪设计通过评审设计评审过程有效（用于检查评审与否有效，与否达到预期，以及交付件质量）设计评审中发现问题都已妥善解决修订后设计阐明书与否纳入文档基线库设计变更控制已经建立设计变更控制流程设计冻结过程原型确认原型设计完毕原型评审执行设计评审中发现问题都已妥善解决原型完整性（可供演示完整页面）进度跟踪与否按进度进行？如进度延期，延期与否在可控范畴内？审核签字角色姓名签字日期软件项目经理研发总监常存在问题存在未攻克技术难题需求基线变动太多而导致设计变化多设计方案不全面，不完整设计方案中所使用技术未经验证开发阶段开发阶段重要从代码规范、代码走查、调测等进行控制管理。质量指引方针商定开发编码规范商定代码审计所需时间及规则商定开发阶段调测方式商定开发阶段自测原则商定提交版本提交原则代码走查走查项走查规定备注规范性编码与否符合项目或组织编码原则头文献包括与否完整参数在限度开始时与否被初始化参数在循环开始时与否被初始化在承数或过程调用时候参数与否被初始化函数调用格式和参数与否对的变量声明和拼写与否一致变量声明范畴与否恰当与否所有指针都被初始化为NULL程序中申请内存使用后与否释放与否每个==，||等都验证了对的性与否打开文献都及时关闭了开发阶段检查单输入条件：项目当前《项目总体筹划》；《代码走查成果清单》；《单元测试成果清单》；《联调测试成果清单》检查项：项目名称项目编号软件项目经理本次检查耗费时间报告人日期检查内容已经完毕某些完毕尚未完毕不合用注释代码开发规范编码与否符合项目或组织编码原则代码开发阶段工作进行代码走审代码走查有效（问题数发现达*个/代码行以上）进行单元测试单元测试有效（问题数发现达*个/代码行以上）进行联调联调与否有效（问题数发现达*个/代码行以上）进度跟踪与否按进度进行？如进度延期，延期与否在可控范畴内？审核签字角色姓名签字日期软件项目经理研发总监常存在问题没有形成项目组内编码规范没有进行代码审查，问题无法被暴露没有进行单元测试导致联调时间加倍增长没有进行联调导致接口级问题非常之多送测版本实际未达到送测规定没有进行联调导致版本送测多次方成功测试阶段质量指引方针尽早介入测试，所有测试都可以追溯到需求在测试相应方案启动之前，必要先理解且分析需求依照质量筹划来制定相应测试筹划测试筹划中需涵盖所有核心质量属性进行测试筹划评审及修订建立测试用例对测试需求覆盖率进行测试用例评审及修订不同测试阶段可有筹划调节当前测试重点评审管理测试评审涉及测试方案、测试用例评审，普通可分为内部评审及外部评审；评审形式按实际质量筹划中规定而定。如下仅提供测试用例评审准则。评审输入《需求规格阐明书》、《概要设计阐明书》、《测试筹划》、《测试用例》、评审准则测试用例评审活动可以保证用例符合先进用例陈述特性，涉及完整、对的、可行、必要、具备优先级、无二义性和可验证性，同步亦符合好用例特性，即完整性、一致性、易修改和可跟踪性；评审过程保证用例满足如下规定：完整性：指有明确目、输入、输出，提供必要备注信息；对的性：指每个用例盼望成果与实际需求一致；可执行性：可执行性指测试人员依照测试用例可以独立执行测试；代表性：指能用最简朴数据，最简捷途径达到测试目；唯一性：指在各个测试用例没有重复交叉现象；有效性：指每个用例与否有效？与否冗余？与否可以执行；独立性：是用例与用例之间与否互不依赖？与否可以独立执行；可读性：指测试用例描述清晰，逻辑对的，拆分合理；质量指标：指与否可以满足质量指标中覆盖率规定，与否可以满足BUG密度质量规定；

内部评审准则评审项评审规定备注完整性针对每个测试需求，与否至少有一种正面用例，与否至少有一种以上反面用例去测试？针对重要测试需求，与否至少使用了两种以上设计办法？唯一性与否存在重复用例？与否存在可以合并用例？与否存在需要拆分用例？与否存在冗余用例？与否存在无效用例？独立性每一种用例目、操作过程、盼望成果与否独立？每一种用例目及盼望成果与否保持统一？盼望成果与否过于发散？可读性不同用例之间针对有关联内容描述与否相似？与否存在互斥、矛盾地方？每个测试用例与否清晰填写了测试特性、环节、预期成果？代表性与否考虑到测试用例执行效率？怎么样环节组合才是最高效？测试用例与否具备指引性,与否能灵活指引测试人员通过用例发现更多缺陷,而不是限制她们思维外部评审准则评审项评审规定备注全面性用例树构造定义与否合理？用例与否涉及如下方面：功能、界面、性能用例及需求中涉及到其他方面用例完整性用例与否覆盖了所有显性需求？用例与否覆盖了所有隐性需求针对每个测试需求，与否从正面、反面分别去验证测试需求？测试用例与否覆盖每个被测功能所有也许输入输出组合？测试用例与否覆盖正常输入输出组合所有也许取值范畴？测试用例与否涉及测试了被测试对象初始化过程？测试用例与否包括了被测对象中所有异常流测试？与否把最多测试用例精力放在系统最重要功能上？针对每个测试用例，与否标记了优先级，且标记合理？针对每个盼望用例盼望成果；对开发规定与否合理？测试开发设计结识与否一致？用例盼望成果理中与需求保持一致？每一种用例依赖数据、盼望成果与否详细到表及字段变化？质量指标用例覆盖率与否达到相应质量指标?用例预期缺陷率与否达到相应质量指标?评审输出《评审成果列表》《评审修订通过测试用例列表》检查清单输入条件：项目当前《项目总体筹划》；《测试筹划/用例文档》、《评审成果单》、测试用例/测试执行/BUG单成果数据项目名称项目编号软件项目经理本次检查耗费时间报告人日期检查内容已经完毕某些完毕尚未完毕不合用注释测试筹划及设计确认测试筹划及用例编制能依照不同质量属性制定不同测试筹划测试用例对需求覆盖达到90%测试评审及跟踪测试筹划评审评审成果清单（用于检查评审与否有效，与否达到预期，以及交付件质量）反馈问题都妥善解决测试用例评审评审成果（用于检查评审与否有效，与否达到预期，以及交付件质量）反馈问题都妥善解决测试跟踪测试执行过程与否被记录及监控BUG单与否被管理质量评估与否进行与否具备测试报告测试报告与否反馈进度跟踪与否按进度进行？如进度延期，延期与否在可控范畴内？审核签字角色姓名签字日期软件项目经理研发总监常存在问题需求或设计变化导致测试时间不够区别哪些会影响核心质量目的，优化测试核心质量目的，对于非核心性质量因素，可后续再做补充测试。测试环境与实际环境无法保持一致而也许导致问题较多。区别影响及不影响功能点。对于影响功能点，在现网布置后，必要再进行现网测试后方可正式投入使用。软件稳定性不够，不可复现问题多稳定测试环境，增长对日记监控及捕获测试用例执行率未达到100%跟进因素，对于非客观因素导致，则可考虑测试用例执行作为项目经理接受测试结束原则。测试用例对需求覆盖率过低提高评审效果，增长用例设计及补充时间段测试用例发现BUG率过低增长用例设计及补充时间段，再进行测试BUG数严重超过预期暂停既有测试，项目组讨论分析再增长单元或联调测试通过扣，方可再进行版本提交。BUG数没有收敛趋势寻找是测试因素导致漏测或是开发总产生新BUG漏测：恰当增长单轮测试时间，强调不同维度测试；多进行交叉测试修改产生过多新BUG：强调开发单元测试及走查。BUG返修率过高在修改BUG过程中强调与测试沟通。BUG修改完毕后，完毕相应自测。测试人员提交BUG单时尽量清晰描述BUG单，并附重现条件或日记。发布及维护阶段质量指引方针依照发布阶段规定准备相应程序及文档及时检查归档各类资源依照项目特性或公网状况制定现网问题跟踪流及管理方式与用服结合制定软件客户满意度调查单发布及维护阶段检查清单项目名称项目编号软件项目经理本次检查耗费时间报告人日期检查内容已经完毕某些完毕尚未完毕不合用注释归档确认版本归档项目经理检查权限回收现网问题跟踪现网问题跟踪流程确认反馈问题管理现网反馈问题已经妥善解决审核签字角色姓名签字日期软件项目经理研发总监常存在问题版本忘掉归档由项目经理检查归档状况，发现未归档者，可及时提出项目经理未对归档进行检查当依照以上检查单发现未版本，则记未归档及项目经理未检查一次；当浮现由于归档资料不全而导致发布给现网浮现问题，则记项目经理未检查一次；现网问题解决状况未进行跟踪定期收集信息，对于管理流程及工具可使用研发部整套模式。质量控制中文档管理质量管理睬形成除项目文档之外管理文档，故文档管理重要为解决项目过程中产生各类文档对的性、唯一性、及时性、有效性所做相应约束。文档分类(1)开发文档：此类文档在软件项目开发过程中，体现了软件开发人员前一阶段工作成果，同步又是后一阶段工作根据。此类文档涉及可行性研究报告、软件项目开发筹划、软件需求规格阐明、系统规格阐明书、软件功能阐明书和数据字典等。(2)管理文档：此类文档在软件项目开发过程中，由软件开发人员制定需提交管理部门某些工作筹划、工作方案和工作报告。通过阅读这些文档，管理人员可以理解软件项目开发活动安排、进度、资源使用等状况。此类文档涉及项目开发筹划、测试筹划、测试方案、开发进度报告和项目总结报告等。(3)顾客文档：此类文档是软件开发人员为使用该软件网点经办人员准备关于该软件产品使用、操作资料，重要是操作手册及新功能简介方面文档。(4)记录文档：与客户交流往来记录、软件项目开发过程中各种会议、跟踪记录、审查记录、产品投产记录和问题跟踪解决记录等。(5)反馈文档：此类文档重要是软件产品在推广使用后来，客户对产品使用过程中意见及产品缺陷、质量等方面信息反馈。文档管理工具文档管理工具当前采用VSS管理方式；存储至文档基线库。文档基线库文档管理基本规定对的性：所有文档都使用相称原则模板文档中所述内容对的无误唯一性：每个版本文档只有一种。及时性：文档随每个任务执行可以及时编制及发布有效性：防止无效文档归档以及过期文档被误用。详细规定：所有文档都使用相应原则模文档发布或归档前得到批准必要时对文献进行定期评审与更新拟定文献更改和现行修订状况得到辨认保证在使用时可获得关于版本合用文献保证文献保持清晰、易于辨认保证外部文献得到辨认并控制其分发防止过期文献被误用，若因任何因素而保存时，需对其进行恰当标记文档管理流程依照既有状态，文档管理流程仅涉及归档及发布，如下图所示：阐明：由作者或相应负责人提出归档申请，必要是评审通过且修改后文档方可提出归档申请与否及时归档检查在各个过程中检查清单中进行检查文档作废：文档归档发布后，需同步作废此文档之前相应版本。每次进行归档后，由归档人员统一进行文档更新发布归档之后文档如有再更新需求，则从基线库取出来进行更新后，重新归档。质量度量：制定项目评估项质量度量重要针对项目进行评估，从项目筹划、过程、质量、成本、客户满意度不同维度进行评估。详细细节如下。筹划评估筹划评估重要依照筹划历史变更记录来评估筹划对的、合理性、可实行状况，并为后来筹划制定提供参照数据。重要针对里程碑进行评估，对于非里程碑筹划变化不进行评估。评估基准1．项目启动时《项目总体筹划》、每次变更后项目筹划、项目结束时《项目总体筹划》2．项目变动记录文献评估项评估项第x次变更变更因素与上次偏离率%与初始偏离率%筹划变更里程碑1里程碑2里程碑3……总结1．筹划变更重要因素是什么？例如项目筹划不够详细，工作安排不够细致，时间挥霍对项目技术、工作量等结识不清，导致筹划时间失误对项目人员工作效率、特长结识不清，导致筹划时间失误项目任务跟踪不及时，错过最佳调节时机过程评估过程评估是依照项目每个阶段质量指引方针以及检查成果来进行评估，用于检查各项目过程控制与否达到应有规定。过程评估最后使用计分方式来得出过程得分。输入条件每个过程每次《过程检查清单》评估登记表评估登记表依照对不同阶段关注不同，定出相应比例，以及每个阶段中不同评估项重点不同，予以不同分值，最后记录出对过程总体评分。过程评估项评估成果最后得分单项分*比例有(√)没有(×)N/A筹划阶段25%项目总体筹划（40分）与否进行总体筹划评审（25分）评审与否有效（发现总体问题60%以上评审称之为有效）（35分）需求阶段25%需求规格阐明书（40分）与否进行了需求评审（30分）评审与否有效在测试阶段发现需求问题少于总问题数5%（30分）设计阶段20%具备方案、概要（详细）设计文档（35分）与否进行设计评审（15分）有否原型设计（20分）与否进行过原型评审（15分）评审与否有效？（如在测试阶段发现UE问题少于总问题数5%）（15分）开发阶段15%与否进行单元测试（25分）单元测试与否有效--发现问题数达到测试阶段问题数10%或以上（15分）与否进行联调（30分）联调与否有效--发现问题数达到测试阶段问题数10%或以上（20分）测试阶段15%有否测试筹划或测试用例（40分）与否进行评审？（20分）评审与否有效？--发现问题数为用例总数10%以上（15分）评审与否有效--用例发现BUG率达90%以上（25分）总计计分准则：有则加分，没有则不加分，N/A则不计算此项；当记录成果中存在不合用此项时，则记录成果需要按100分再进行一次转换；例如测试阶段分别记录为：1有；2无；3N/A，4有；则测试阶段得分为：（40+25）/（40+20+25）*100*15%；总结对过程得出最后分进行分析：哪些过程存在严重质量问题？哪些过程缺少哪些质量控制环节？哪些质量控制环节没有起到相应作用？项目质量评估质量评估重要依照测试成果质量评估以及现网问题跟踪状况进行评估。输入条件1．《版本质量评估报告》2．现网问题跟踪表评估项测试阶段评估重要根据测试各类数据依照质量评估原则进行质量评估。维护阶段评估重要依照现网问题清单对缺陷率、平均缺陷时间来进行质量评估缺陷率：指现网问题数/总问题率平均缺陷时间（MTF）：指平均多久时间反馈一种问题。平均缺陷恢复时间：指浮现一种缺陷后，恢复所需要时间。评估项评估成果备注测试阶段（单版本质量评估）第一次第二次第三次维护阶段评估缺陷率其他记录平均缺陷时间缺陷恢复时间缺陷修复时间缺陷细分需求问题/所有现网问题比率功能问题/所有现网问题比率UE问题/所有现网问题比率其他问题/所有现网问题比率总结对质量状况得出来评估成果进行分析。测试成果反馈状况重要是哪些环节中问题现网问题反馈状况重要是哪些环节中问题测试成果反馈状况与现网问题反映成果与否一致通过以上总结分析出哪个阶段所存在问题最多，测试办法/方略与否存在问题；改进明确存在问题环节。成本评估成本评估重要用于评估在各阶段成本投入比较与否合理，质量控制成本投入与否合理，与否存在成本挥霍等状况。输入条件项目初始时《项目总体筹划》项目结束时《项目总体筹划》、《项目开发筹划》、《测试筹划》评估项筹划成本指耗费在筹划环节中所费成本，依照最后项目总体筹划记录需求阶段成本需求成本指耗费在需求环节所费成本；依照最后项目总体筹划记录需求阶段成本设计成本指耗费在设计环节所费成本；涉及概要设计、原型设计、详细设计等内容工作成本。开发成本指纯开发阶段所费成本。质量成本记录所有因质量活动而引起成本，分好成本、坏成本，好成本涉及各防止性质量控制，如评审、质量检查、测试；坏成本指各种返修成本。好质量成本评审所有活动成本测试所有活动成本培训等支出费用坏质量成本各种评审后返修成本测试之后所有回归修改成本其他成本非以上成本之外其他成本，涉及其他某些管理活动、沟通、协调等成本。评估项人/日占总体%与初始筹划相比（增长或减少%）简析筹划成本需求成本设计成本开发成本质量成本好质量成本坏质量成本其他成本总计总结通过以上数据结合其他评估成果分析在各阶段投入成本与否合理，哪些成本是可以通过合理