软件产品的质量定义始终都是满足要求和适合使用，高质量和高等级是有区别的。软件质量目标应该来源于商业目标驱动，商业目标决定了软件的价值。提高软件质量的目标仍然是为了盈利和创造更大的效益，而不是创造完美无缺的产品。
软件产品质量不是靠测试和评审出来的，而是靠设计出来的。关注软件项目中的好质量成本和坏质量成本可以宏观的看到项目软件质量管理的水平。对于软件项目COQ一般在35%-55%，而坏质量成本一般在8-15%，这也说明我们要尽量减少返工，争取第一次就把事情做对。
1.软件的质量属性和质量要素
PMBOK中质量的定义是符合要求和适合使用。CMM对质量的定义是一个系统，组件或过程符合客户或用户的要求或期望的程度。因此可以讲质量更多不是研发者说的，而是用户的最终感受。
通过类比，我们这样理解软件质量：软件质量是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。人们通过改善软件的各种质量属性，从而提高软件的整体质量（否则无从下手）。
软件的质量属性很多，如正确性、精确性，健壮性、可靠性、容错性、性能、易用性、安全性、可扩展性、可复用性、兼容性、可移植性、可测试性、可维护性、灵活性等。这些质量属性又可以分为功能性和非功能性两大类。
功能性质量要素:正确性，健壮性，可靠性
非功能性质量因素：性能，易用性，安全性，可扩展性，兼容性，可移植性
a.正确性:第一重要，机器不会欺骗人，软件运行错误都是人为造成的。
b.健壮性:包括容错能力和恢复能力，开发过程中应该充分考虑各种异常和边界。
c.可靠性:可靠性是指在一定的环境下，在给定的时间内，系统不发生故障的概率。
d.性能：性能通常是指软件的“时间-空间”效率，而不仅是指软件的运行速度。(性能问题解决根本还是算法和程序的优化，而不是期待硬件的更高配置)
e.易用性:易用性是指用户使用软件的容易程度。(界面友好仅仅是一方面，还包括人机工程很多内容)
f.安全性:安全性是指防止系统被非法入侵的能力
g.扩展性:反映了软件应对变化的能力
h.兼容性:对硬件的兼容，对软件的兼容
非功能性需求是软件质量重要组成，是架构设计和软件产品化的重要考虑，但往往容易被忽视。特别是在开发通用性的产品的时候，非功能性质量要素必须要考虑全面。
什么是质量要素，应该理解为能够提高用户满意度和提高产品核心竞争力和价值的质量属性。如果某些质量属性并不能产生显著的经济效益，我们可以忽略它们，把精力用在对经济效益贡献最大的质量要素上。简而言之，只有质量要素才值得开发人员下功夫去改善。
2.商业目标决定质量目标
重视软件质量是应该的，但是“质量越高越好”并不是普适的真理。只有极少数软件应该追求“零缺陷”，对绝大多数软件而言，商业目标决定了质量目标，而不该把质量目标凌驾于商业目标之上。
企业的根本目标是为了获取尽可能多的利润，而不是生产完美无缺的产品。如果企业销售出去的软件的质量比较差，轻则挨骂，重则被退货甚至被索赔，因此为了提高用户对产品的满意度，企业必须提高产品的质量。但是企业不可能为了追求完美的质量而不惜一切代价，当企业为提高质量所付出的代价超过销售收益时，这个产品已经没有商业价值了，还不如不开发。
企业必须权衡质量、效率和成本，产品质量太低了或者太高了，都不利于企业获取利润。企业理想的质量目标不是“零缺陷”，而是恰好让广大用户满意，并且将提高质量所付出的代价控制在预算之内。
3.质量保证能够保证质量吗
软件质量保证（Quality Assurance）的目的是为管理者提供有关软件过程和产品的适当的可视性。它包括评审和审核软件产品及其活动，以验证其是否遵守既定的规程和标准，并向有关负责人汇报评审和审核的结果。
简而言之，质量保证活动就是检查软件项目的“工作过程和工作成果”是否符合既定的规范。如此简单的活动为什么被冠以“质量保证”这等份量的术语呢？没有历史典故，经我考究，猜想是源于一个天真的假设：
过程质量与产品质量存在某种程度的因果关系，通常“好的过程”产生“好的产品”，而“差的过程”将产生“差的产品”。假设企业已经制定了软件过程规范，如果质量保证人员发现某些项目的“工作过程以及工作成果”不符合既定的规范，那么马上可以断定产品存在缺陷。反之，如果质量保证人员没有发现不符合既定规范的东西，那么也可以断定产品是合格的。
符合既定规范的东西并不意味着质量一定合格，仅靠规范无法识别出产品中可能存在的大量缺陷.
4.全面软件质量管理模型
提高软件质量最好的办法是：在开发过程中有效地防止工作成果产生缺陷，将高质量内建于开发过程之中。主要措施是“不断地提高技术水平，不断地提高规范化水平”，其实就是练内功，通称为“软件过程改进”。
其次方法是当工作成果刚刚产生时马上进行质量检查，及时找出并消除工作成果中的缺陷。这种方式效果比较好，人们一般都能学会。最常用的方法是技术评审、软件测试和过程检查，已经被企业广泛采用并取得了成效。
最差的是在软件交付之前，没有及时消除缺陷。当软件交付给用户后，用着用着就出错了，赶紧请开发者来补救。可笑的是，当软件系统在用户那里出故障了，那些现场补救成功的人倒成了英雄，好心用户甚至还寄来感谢信。
谁对软件质量负责？是全员负责。任何与软件开发、管理工作相关的人员都对质量产生影响，都要对质量负责。所以人们不要把质量问题全部推出质量人员或测试人员。
谁对软件质量负最大的责任？谁的权利越大，他所负的质量责任就越大。质量人员是成天与质量打交道的人，但他个人并不对产品质量产生最大的影响，所以也不负最大的责任。
质量人员的主要职责：
1.负责制定质量计划（很重要但是工作量比较少）；
2.负责过程检查（类似于CMM中的质量保证），约占个人工作量的20%；
3.参与技术评审，约占个人工作量的30%；
4.参与软件测试，约占个人工作量的30%；
5.参与软件过程改进（面向整个机构），约占个人工作量的20%；
质量管理计划的主要内容（模板见word文件）：
1. 质量要素分析
2. 质量目标
3. 人员与职责
4. 过程检查计划
5. 技术评审计划
6. 软件测试计划
7. 缺陷跟踪工具
8. 审批意见
5.技术评审
技术评审（Technical Review, TR）的目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。技术评审最初是由IBM公司为了提高软件质量和提高程序员生产率而倡导的。技术评审方法已经被业界广泛采用并收到了很好的效果，它被普遍认为是软件开发的最佳实践之一。
技术评审的主要好处有：
1.通过消除工作成果的缺陷而提高产品的质量；
2.技术评审可以在任何开发阶段执行，不必等到软件可以运行之际，越早消除缺陷就越能降低开发成本；
3.开发人员能够及时地得到同行专家的帮助和指导，无疑会加深对工作成果的理解，更好地预防缺陷，一定程度上提高了开发生产率。
技术评审有两种基本类型：
1.正式技术评审FTR。FTR比较严格，需要举行评审会议多。
2.非正式技术评审ITR。ITR的形式比较灵活，通常在同伴之间开展，不必举行评审会
技术评审和软件测试的目的都是为了消除软件的缺陷，两者的主要区别是：
1.前者无需运行软件，评审人员和作者把工作成果摆放在桌面上讨论；
2.而后者一定要运行软件来查找缺陷。技术评审在软件测试之前执行，尤其是在需求开发和系统设计阶段。
相比而言，软件测试的工作量通常比技术评审的大，发现的缺陷也更多。在制定质量计划的时候，已经确定了本项目的主要测试活动、时间和负责人，之后再考虑软件测试的详细计划和测试用例。
如果机构没有专职的软件测试人员的话，那么开发人员可以兼职做测试工作。当项目开发到后期，过程检查和技术评审都已经没有多少意义了，开发小组急需有人帮助他们测试软件，如果质量人员参与软件测试，对开发小组而言简直就是“雪中送炭”。
强调：质量人员一定要参与软件测试（大约占其工作量的30％左右），只有这样他才能深入地了解软件的质量问题，而且给予开发小组强有力地帮助。
CMM和ISO9001所述的软件质量保证，实质就是过程检查，即检查软件项目的“工作过程和工作成果”是否符合既定的规范。
“过程检查”这个词虽然没有质量保证那么动听，但是其含义直接明了，不会让人误解。为了避免人们误以为“质量保证”能够“保证质量”，我提议用“过程检查”取代质量保证这个术语。
虽然本章批判了“质量保证”的浮夸，但是并没有全盘否定质量保证的好处。过程检查对提高软件质量是有帮助的，只是它的好处没有象质量保证鼓吹的那么好而已。
符合规范的工作成果不见得就是高质量的，但是明显不符合规范的工作成果十有八九是质量不合格的。例如版本控制检查,再例如，机构制定了重要工作成果的文档模板（例如需求规格说明书、设计报告等），要求开发人员写的文档尽可能符合模板。如果质量人员发现开发人员写的文档与机构的模板差异非常大，那么就要搞清楚究竟是模板不合适？还是开发人员偷工减料？
过程检查的要点是：找出明显不符合规范的工作过程和工作成果，及时指导开发人员纠正问题，切勿吹毛求疵或者在无关痛痒的地方查来查去。
不少机构的质量人员并没有真正理解过程检查的意义，老是对照规范，查找错别字、标点符号、排版格式等问题，迷失了方向，这样只有疲劳没有功劳，而且让开发人员很厌烦。
对于中小型项目而言，过程检查工作由质量人员一个人负责就够了，约占其20％的工作量，让质量人员抽出更多的时间从事技术评审和软件测试工作。
最新内容请见作者的GitHub页：http://qaseven.github.io/