软件项目质量计划

第八章 软件项目质量计划

8.1 软件质量基本概念

8.1.1 软件质量相关概念

质量定义
质量
质量是产品或服务满足明确和隐含需要能力的性能特性的总体
软件质量
与软件产品满足规定的和隐含的需求能力有关的特征或特性的全体
软件质量是软件满足明确说明或者隐含的需求的程度

软件质量反映了以下三方面的问题:

1. 软件需求是度量软件质量的基础，不满足需求的软件就不具备质量
2. 不遵循各种标准中定义的开发规则，软件质量就得不到保证
3. 只满足明确定义的需求，而没有满足应有的隐含需求，软件质量也得不到保证

质量是“一个实体的性能总和，它可以凭借自己的能力去满足 对它的明示或暗示的需求"
在项目管理中，质量管理的既定方向就是通过项目范围界定管理体制 ，将暗示的需求变为明示的需求

质量与等级
等级
是对具有相同功能的实体按照不同技术特征进行分类或者分级

质量
论产品釆用任何等级标准，它都应该具备能满足相应功能要求的各种特征, 这些特征的总和就是质量

质量标准
企业、国家或者国际制定的对某个方面的规范，与质量政策相比，更侧重质量的细节特征，属于微观的范畴

质量策略
某个组织针对自身要求制定的一种质量指导方针，更侧重于指导思想，属于宏观的范畴

质量责任
整个组织都对项目质量负有的责任，但是如果没有明确和细化责任，就会形成人人有责、人人不负责的局面
质量 责任包括管理层的责任、最终责任、首要责任等

质量成本
质量管理 也是需要成本的，也就是说要采取行动就要有所花费
包括两部分：

• 预防成本，为了确保质量而进行的预防工作的消耗
  • 评估费用,使项目符合所提要求（第一次）检测缺陷所衍生成本
  • 预防费用,使项目符合所提要求预防失败所衍生成本
• 缺陷成本，为了确保质量而修复缺陷所消耗的成本
  • 内部费用,对于不能符合所提要求，尚未发行的软件（返工）所衍生的费用，如返工，重新测试
  • 外部费用,对于已经发布但是不符合要求的软件所衍生的费用
    预防重于事后检查，预防成本应该大于缺陷成本
    质量成本还包括：项目返工的管理时间，丧失的信誉，商机和客户好感等

质量的形成
质量形成于产品或者服务的开发过程中，而不是事后的检查
一个高质量的产品是开发出来的。产品的质量只能靠前期的质量预 防和质量检测保证，如代码走查、单元测试、对等评审等
后期的测试不能真正提高产品的质量

8.1.2 软件质量模型

通常把影响软件质量的特性用软件质量模型来描述

Boehm模型
一种由纵向软件特征构成的层次模型
将软件质量分解为若干层次，对于最底层的软件质量概念再引入数量化的指标，从而得到软件质量的整体评价
Boehm模型包括McCall模型没有的硬件领域的质量要素

McCall模型
与Boehm模型唯一的差别在于特征的种类
McCall模型的最大贡献在于，它建立了软件质量特征和软件度量项之间的关系
有些度量项不是客观指标，而是主观判断
McCall模型没有从软件生存周期不同阶段的存在形态来考虑，而仅仅考虑一种产品形态，不利于在软件产品早期发现缺陷和 降低维护成本

ISO/IEC9126模型
根据软件质量国家标准GB/T 8566-2001，软件质量评估通常从对软件质量框架的分析开始
软件质量框架是一个“质量特征一质量子特征一度量因子”的三层结构模型

如果某些质量属性并不能产生显著的经济效益，我们可以忽略它们 ，把精力用在对经济效益贡献最大的质量要素上
只有质量要素才值得开发人员下工夫去改善

质量要素包括两方面的内容:

1. 技术角度，对软件整体质量影响大的质量属性才是质量要素
2. 商业角度，客户关系的，能成为卖点的质量熟悉才是质量要素

ISO/IEC 9126模型的贡献在于将软件质量特征分为外部特征和内部特征
考虑到软件产品不同生命周期阶段的不同形态问题
但该模型没有清楚给出软件质量特征如何去度量
软件质量模型 - ISO/IEC25010模型
在ISO9126模型的基础上制定的
仍然是一个“质量特征—质量子特征—度量 因子”的三层结构模型

8.2 质量管理活动

软件项目的质量管理：保证项目满足其目标要求所需要的过程
关键在于：预防重于检查，事前计划好质量而非事后检查
对象是：过程（的质量）、产品（的质量）
目的：

• 确保项目工期
• 实现系统功能，达到系统的性能指标以及系统运行的可靠性
• 规定质量保证措施，资源及活动应具有的顺序
• 确保产品的实现过程受控有效，完成的项目满足用户的要求

质量不仅拥有发言权，而且对项目的成败拥有表决权甚至最终的否决权
质量一般通过定义交付物标准来明确定义
这些标准包括各种特性及这些特性需要满足的要求。还包含对项目过程的要求
质量管理主要是监控项目的交付物和执行过程

8.2.1 软件质量计划

软件质量计划过程是确定项目应达到的质量标准(目标)，以及决定如何满足质量标准的计划安排和方法

1. 首先确定项目质量目标
   根据wbs将目标分解到工作包，并按职责分工将工作包的质量目标落实到每个小组成员
2. 对于一个项目，可建立项目的质量模型，以此确定项目的质量目标 ，或质量标准
   

8.2.2 软件质量保证 QA

质量保证是为了提供信用，证明项目将会达到有关质量标准而开展的有计划、有组织的工作活动
质量保证可以确保对项目进行客观公正的审核和评价
软件开发过程中，质量保证的主要任务是对项目执行过程和项目产品进行检查，验证他们与项目采用的过程和标准的一致性
质量保证人员的职责是规划和维 护质量过程，以便实现项目的目标
定期对项目质量计划的执行情况进行评估、审核与改进等工作
在项目出现偏差的时候提醒项目管理人员
提供项目和产品可视化的 管理报告

质量审计
是对过程或者产品的一次独立评估
将审核的主体与为该主体以前建立的一组规程和标准进行比较
目的是确保真正的遵循了这一个过程，产生合适的文档和精确反映实际项目的报告
项目审计可以事先规划，也可以是临时决定的

项目执行过程审计
需求过程审计，设计过程审计，编码过程审计，测试过程审计
项目产品审计
需求规格审计，设计说明书审计，代码审计，测试报告审计

8.2.3 软件质量控制QC

质量控制：确定项目结果与质量标准是否相符，同时确定不符的原因和消除方法，控制产品的质量，及时纠正缺陷的过程

质量控制方法

• 技术评审
• 走查
• 测试
• 返工

8.2.4 质量保证和质量控制

质量保证	质量控制
是审计产品和过程的质量，保证过程被正确执行，确认项目按照要求进行	检验产品的质量，保证产品符合客户的需求，是产品质量检查者
质量保证人员，管理职能	开发人员，检查职能
注重过程和产品提交后的质量管理	注重产品推出前的质量把关
这个任务本身并不直接提高本版本产品的质量	可直接提高产品的质量
Is it done right?” （完成的是否正确?)	“Is it right done?”（是否正确完成?）

8.3 敏捷项目的质量活动

敏捷项目质量管理特征

• 提倡全程质量审查，有贯穿始终的质量活动
• 提倡早发现问题
• 不断进行质量方法评估和改进
  实现敏捷质量策略的活动很多
• 质量保证(QA)活动：迭代评审，迭代回顾会议等
• 质量控制(QC)活动：结对编程，测试驱动开发，持续集成与测试，不同层面测试，验收测试驱动开发，重构等

8.3.1 敏捷项目的质量活动

结对编程
结对编程过程，即两个人一起在计算机前编码，互相评审代码
提高代码质量和项目效率
测试驱动开发
在明确要开发某个功能后，首先思考如何对这个功能进行测试，并 完成测试代码的编写，然后编写相关的代码以满足这些测试用例。 循环进行此过程添加其他功能，直到完成全部功能的开发
持续集成与测试
敏捷项目要求频繁地将工作集成到整体系统中，然后进行重新测试 ，以确定整个产品仍然按照预期工作
不同层面自动化测试
包括单元测试、集成测试、系统测试、冒烟测 试、回归测试等不同层次的测试
验收测试驱动开发
首先与客户一起讨论工作产品的验收标准，然后团队创建测试用例 ，并基于此编写足够的代码，进行自动化测试，以使产品满足标准 要求
迭代评审
迭代完成之后，向项目相关人员展示本迭代版本的运行情况，得到 用户反馈
迭代回顾会议
迭代完成之后，评审本迭代过程，确定是否进行过程改进
重构
重构是在每个迭代之后再逐步完善代码和设计的过程，其基本思路 是先完成代码的正常功能，然后逐步地提高代码的质量
频繁评审 代码，完善设计

8.4 软件项目质量计划

8.4.1 质量计划

软件质量计划过程是确定项目应达到的质量标准(目标)，以及决定如何满足质量标准的计划安排和方法
首先确定项目质量目标，根据wbs将目标分解到工作包，并按职责分工将工作包的质量目标落实到每个小组成员
对于一个项目，可建立项目的质量模型，以此确定项目的质量目标 ，或质量标准

8.4.2 编制质量计划的方法

编制项目的质量计划，首先必须确定项目的范围、中间产品和最终 产品
然后明确关于中间产品和最终产品的有关规定、标准，确定可能影 响产品质量的技术要点并找出能确保高效满足相关规定，标准的过 程方法
试验设计
一种统计学方法，确定哪些因素可能会对特定变量产生影响
是在可选的范围内，对特定要素设计不同的组合方案，通过推演和 统计，权衡结果，以寻求优化方案
基准对照
一种寻找最佳实践的方法,利用其他项目的实施情况作为当前项目性能衡量的标准
通过审査项目的提交结果、项目管理过程、项目成功或者失败的原因等来衡量本项目的绩效
质量成本分析
质量成本是为了达到满足用户期望的交付结果的质量要求而花费的所有成本
这包括为满足质量需求而做的所有工作和解决不合格项而付出的花费
所以，编制质量计划必须进行质量成本的综合分析，以便决定质量活动
测试与检查的规划
在规划阶段，项目经理和项目团队可以决定如何测试或检查产品、 可交付成果或服务，以满足相关方的需求和期望，以及如何满足产品的绩效和可靠性目标
流程图方法
流程图方法可以显示系统的各种成分之间的相互关系
可以帮助我们预测在何处可能发生何种质量问题
并由此帮助开发处理这些质量问题的办法
因果分析图
对于复杂的项目，编制质量计划时可以釆用
因果分析图描述相关的各种原因和子原因如何产生潜在问题或影响
将影响质量问题的人员、设备、参考资料、方法、环境等各方面的原因进行细致的分解
方便在质量计划中制定相应的预防措施

思维导图
质量思维导图通常是基于单个质量概念创建的，是绘制在空白页面中央的图像，之后再增加以图像、词汇或词条形式表现的想法
思维导图有助于快速收集项目质量要求、制约因素、依赖关系和联系

8.4.3 质量计划的编制

规划出哪些是需要被跟踪的质量工作，并建立文档
质量计划应满足要求：

• 应达到的质量目标和所有特性的要求
• 确定质量活动和质量控制程序
• 确定项目不同阶段的职责，权限，交流方式以及资源分配
• 确定采用的控制手段，合适的验证手段和方法
• 确定和准备质量记录
  目标可以根据项目的质量模型确定相关的质量属性或者确定根据质量模型的 计算值，质量属性可以根据具体项目选择
  可用度
  指软件运行后在任一随机时刻需要执行规定任务或完成规定功能时 ，软件处于可使用状态的概率
  初期故障率
  指软件在初期故障期（一般以软件交付给用户后的3个月内为初 期故障期）内单位时间的故障数
  一般以每100小时的故障数为单位。
  偶然故障率
  指软件在偶然故障期（一般以软件交付给用户后的4个月以后为偶然故障期）内单位时间的故障数。一般以每1000小时的故障数为单位。它反映了软件处于稳定状态下的质量
  平均失效前时间
  指软件在失效前正常工作的平均统计时间
  平均失效间隔时间
  指软件在相继两次失效之间正常工作的平 均统计时间
  缺陷密度
  软件单位源代码中隐藏的缺陷数量
  平均失效恢复时间
  软件失效后恢复正常工作所需的平均 统计时间

编制一份清晰的质量计划是实施项目质量管理的第一步
质量计划中要明确质量管理组织的职责和义务。质量保证的人员应该有特殊的问题上报渠道，以保证问题顺利解决，但是质量保证人员应该慎用这个渠道
项目经理是项目质量管理的最终责任承担者

输出形式没有统一标准.关键是将质量活动体现出来， 以便在项目执行过程中参照执行
第一种形式是将质量活动体现在进度计划的活动中
另外一种是以文档形式输出

8.5 软件质量改善的建议

为了更好地进行软件质量的改善，有如下的建议

1. 不但要主观认识到质量的重要性，而且要落实到行动中。把想法落实到实际工作中是做好软件质量管理的第一原则
2. 软件质量活动必须经过规划，必须明文规定
3. 树立提高质量就是尊重客户的思想
4. 质量活动必须尽早开始
5. 质量小组尽可能独立存在
6. 质量小组的人应该经过必要的培训