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.主要的质量要性如下：
功能性质量因素：正确性，健壮性，可靠性
非功能性质量因素：性能，易用性，清晰性，安全性，可扩展性，兼容性，可移植性
其它质量因素：非以上要求之外的要求。
2.根据产品的特性及市场目标，将关键的质量要素确认，同时区分本项目的类型倾质量型项目：指本项目对质量控制更关注
倾成本型项目：指本项目对成本控制更关注
倾工期型项目：指本项目对工期要求更关注
根据以上分析，再制定相应的质量目标。
1.2.1.2质量目标
订立质量目标时，一般遵循SMART原则
S：specific具体的
M：measurable可测量的
A：achievable可取得的
R：realistic切实的
T：timely及时的
根据以上原则，我们可以制定如下质量目标：
1.比如本项目的质量要素为功能正确性、功能健壮性、性能
那质量目标可定义例下：
需求中所定义的功能都得以实现
不稳定问题（等级非轻微）都被解决
关键模块（模块名称）的性能不能低于V1.0版本
2.针对质量目标定出优先级
1、3、2
3.目标分解
分解为阶段质量目标
完成阶段质量目标的手段
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过程检查计划
1.2.2维护性项目质量计划要求
维护性项目的质量计划制定相对简单，不需要花较多的时间在其上，并且可以套用比较固定的模板。
维护性项目基本上会有很明确的需求点以及具体的时间点要求，一般情况下，维护时期会很长，且需求相对较散、小，针对这些特性，维护性项目的质量计划要求仅可以包括：质量目标、质量保障计划、过程检查计划。
1.2.2.1质量目标
根据当前的需求简单定出本版本的质量目标。
1.2.2.2质量保障计划
在维护性项目中，质量保障计划主要包括：需求讨论、联调以及测试。
需求讨论：参与人员包括开发及测试人员；需求讨论结果报告
联调：对所做的修改及周边进行联调；联调测试报告
测试：根据质量目标制定相应的测试计划安排，
1.2.2.3过程检查计划
无论质量目标定为如何，维护性项目的过程检查，仅需要如下环节：
需求讨论会：是否进行了需求讨论会，需求讨论会的与会人员及结果
联调：是否进行了联调，对原版本的影响
测试执行：对测试过程进行检查
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.3.1.2.3评审输出
评审结果输出包括：
1.《评审结果记录表》
1.3.2需求阶段
需求阶段指从需求获取至输出需求规格说明书阶段。需求阶段可划分为：获取需求、分析需求、编写需求规格说明书三个阶段。
1.获取需求：主要从编写项目视图与范围、用户群分类、选择产品/项目需求代表、确
定使用实例、分析工作流程、需求重用这几步骤进行
2.分析需求：包括绘制关联图、创建开发原型、分析可行性、划分需求优先级；
3.编写需求规范说明书：根据项目特点裁剪模板、获取功能和技术需求、注明需求来源、
开发需求追踪矩阵。
1.3.2.1质量指导方针
根据《需求模板》、《需求编写指导说明书》制定需求说明文档
需求文档中应包括明确的需求范围
需求文档中应包括主要的质量属性
需求需细化到要求的程度（可以根据需求进行开发设计及测试设计）
需求的不确定项不超过总体需求的5%
需求中应明确定义需求的优先级
制定需求管理原则（包括需求标识、跟踪方式、变更控制原则）
1.3.2.2评审管理
需求阶段评审主要针对需求的清晰性、正确性、完整性、可管理性进行评审。评审的形式按实际的质量计划中要求而定。
1.3.2.2.1评审输入项
《技术方案建议书》、《需求分析》、《需求规格说明书》1.3.2.2.2评审准则
需求评审时，主要针对需求的清晰性、正确性、完整性、可行性、可管理性进行评审，评审细项如下图所示：
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.
可追溯性17.
18.评审要求设计说明书的编写是否按照标准模板来编写设计是否正确是否能够满足需求设计方案在现有条件下是否可行设计方案是否能被相关人员理解是否包括核心功能的实现方案所有的功能需求与非功能需求是否都体现在了设计中在设计中是否增加了不必要的功能是否为未来的变更进行了过渡设计各子系统、模块之间的关系是否描述得清楚系统的设计是否考虑了系统的可扩展性设计是否考虑了重用性重用构件是否进行了标识是否说明了重用模块的获取方式和相关的文档系统的设计是否考虑了系统的易移植性设计是否使用标准的技术，避免使用怪异的、不易理解的方式和方法设计的调用宽度、调用深度、耦合度、内聚度和结构化程度是否进行了描述设计是否可以跟踪到需求需求是否可以追溯到设计
1.3.3.2.3评审输出
《评审结果列表》、评审修订后的《概要设计文档》
1.3.4开发阶段
开发阶段主要从代码规范、代码走查、调测等进行控制管理。
1.3.4.1质量指导方针
1.约定开发的编码规范
2.约定代码审计所需的时间及规则
3.约定开发阶段的调测方式4.约定开发阶段自测的标准5.约定提交版本提交的原则
1.3.4.2代码走查
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评审准则
测试用例评审活动可以确保用例符合优秀用例陈述的特征，包括完整、正确、可行、必要、具有优先级、无二义性和可验证性,同时亦符合好的用例特征，即完整性、一致性、易修改和可跟踪性；评审过程保证用例满足如下要求：
完整性：指有明确的目的、输入、输出，提供必要的备注信息；
正确性：指每个用例的期望结果与实际需求一致；
可执行性：可执行性指测试人员根据测试用例能够执行测试；
代表性：指能用的数据，最简捷的路径达到测试的目的；
唯一性：指在各个测试用例没有重复交叉的现象；
有效性：指每个用例是否有效是否冗余是否能够执行；
性：是用例与用例之间是否互不依赖是否能够执行；
可读性：指测试用例描述清晰，逻辑正确，拆分合理；
质量指标：指是否能够满足质量指标中的覆盖率要求，是否可以满足BUG密度的质量
内部评审准则
外部评审准则
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文档管理的基本要求
正确性：所有的文档都使用相当的标准模板文档中所述的内容正确无误
唯一性：每个版本的文档只有一个。
及时性：文档随每个任务的执行能够及时编制及公布
有效性：防止无效的文档归档以及过期文档被误用。
具体要求：
1.所有的文档都使用相应的标准模
2.文档发布或归档前得到批准
3.必要时对文件进行定期评审与更新
4.确定文件的更改和现行修订状况得到识别
5.确保在使用时可获得有关版本的适用文件
6.确保文件保持清晰、易于识别
7.确保外部文件得到识别并控制其分发
8.防止过期文件被误用，若因任何原因而保留时，需对其进行适当的标识
1.3.7.4文档管理流程
根据现有的状态，文档的管理流程仅涉及归档及发布，如下图所示：
一般，必须是评审通过且修订后的文档方提交归档申请
/修订等信息
由作者或相应负责人提出归档申请，必须是评审通过且修改后的文档方可提出归档申请
是否及时归档的检查在各个过程中的检查清单中进行检查
文档作废：文档归档发布后，需同时作废此文档之前的相应版本。
每次进行归档后，由归档人员统一进行文档更新发布
归档之后的文档如有再更新的需求，则从基线库取出来进行更新后，重新归档。
1.4质量度量：制定项目评估项
质量度量主要针对项目进行评估，从项目的计划、过程、质量、成本、客户满意度不同维度进行评估。具体细节如下。
1.4.1计划评估
计划评估主要根据计划历史变更记录来评估计划的正确、合理性、可实施情况，并为以后的计划制定提供参考数据。主要针对里程碑进行评估，对于非里程碑的计划变化不进行评估。
1.4.1.1评估基准
1．项目启动时的《项目总体计划》、每次变更后的项目计划、项目结束时的《项目总体计划》
2．项目变动记录文件
1.4.1.2评估项
第_次变更
里程碑1计划
里程碑2变更
里程碑3
变更原因
与上次偏离率%
与初始偏离率%
1.4.1.3总结
1．计划变更的主要原因是什么比如
项目计划不够详细，工作安排不够细致，时间浪费对项目的技术、工作量等认识不清，导致计划时间失误对项目人员的工作效率、特长认识不清，导致计划时间失误项目任务跟踪不及时，错过最佳调整时机
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评估项
测试阶段评估主要依据测试各类数据根据质量评估标准进行质量评估。
维护阶段评估主要根据现网问题清单对缺陷率、平均缺陷时间来进行质量评估缺陷率：指现网问题数/总问题率
平均缺陷时间（MTF）：指平均多久时间反馈一个问题。
平均缺陷恢复时间：指出现一个缺陷后，恢复所需要的时间。
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.质量成本
统计所有因质量活动而引发的成本，分好成本、坏成本，好的成本包括各预防性的质量控制，如评审、质量检查、测试；坏的成本指各种返修成本。好质量成本
1)评审所有活动的成本
2)测试所有活动的成本
3)培训等支出的费用
坏质量成本
1)各种评审后的返修的成本
2)测试之后的所有回归修改成本
6.其它成本
非以上成本之外的其它成本，包括其它的一些管理活动、沟通、协调等成本。
1.4.4.3总结
通过以上数据结合其它评估结果分析在各阶段投入的成本是否合理，哪些成本是可以通过合理的调整来避免的，哪些成本投入应该增加。
1.4.5客户满意度评估
客户满意度评估主要是由用服协助通过客户满意度调查结果、意见反馈单得到的数据而进行的评估。
1.4.5.1输入条件
《客户满意度调查结果》、《意见反馈表》
1.4.5.2评估项
1.4.5.3总结
客户对非质量目标的满意度高于质量目标：质量保证与控制手段对质量目标未起到作用客户对质量目标不关注，更关注非质量目标：质量目标定义不合理客户要求支持的次数过多：客户总要求我方支持，是否可理解性过差客户要求支持的时间过长：每次支持的时间过长，是否可维护性过差
1.5质量改进
质量改进整个质量管理中最后的一个环节，也是一个新的质量管理实施的基础。质量改进环节主要根据项目评估结果，去分析现存在的质量问题及针对问题找出相应的质量改进措施。
1.5.1现存在的质量问题
在每个项目告一阶段后，分析整理现在各项目中普遍存在的质量问题，区分主观问题及客观问题；并对存在的质量问题进行原因分析。
1.5.2质量改进措施
针对提练出来的质量问题，提出改进措施，并在新项目的质量管理环节中实施，跟进实施的效果。
下载本文